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SU>mRY 


rhi'i  roport  is  an  invest  i p, a t Inn  of  llie  feasibility  of  using  mlnl- 
conputers  in  a (list  libuted  processing  configuration  for  tlie 
blight  Service  Station  modernization  program.  It  is  based  on 
studies  of  existing  distributed  processing  configurations,  many 
ol  wliicli  were  visited  by  members  of  tlie  MITRE/FAyX  distributed 
proi-essing  study  team;  on  information  supplied  by  vendors;  and 
on  an  analysis  of  two  sample  configurations  taking  into  account 
available  data  concerning  Fliglit  Service  Station  (FSS)  functions. 

During  the  course  of  the  investigation,  it  became  apparent  that 
while  distributed  processing  is  widely  discussed  and  advocated, 
implemented  systems  are  relatively  few  in  number,  and  none  has  the 
lo.ad  or  complexity  anticipated  for  an  FSS  Hub.  Minicomputer 
sottware  also  emerged  as  lagging  beliind  in  development  relative  to 
haniware.  However,  at  least  one  vendor  does  offer  in  packaged  form 
tlie  hardware  and  software  necessary  for  distributed  systems  such 
as  the  FSS,  though  to  date  this  vendor  has  not  assembled  a multi- 
proct'ssor  system  as  large  as  that  needed  for  an  FSS.  The  sample 
FSS  designs  are  based  on  this  hardware,  and  are  configured  as  a 
load  sharing  system  and  as  a function  sharing  configuration.  Result 
of  .in  analysis  of  these  configurations  indicate  that  the  functions 


iii 


of  an  FSS  could  he  handleii  by  them,  with  comlortahle  reserve*  capacity. 
A summary  of  the  performance  of  these  systems  under  peak  loading  con- 
ditions is  shown  In  Table  1. 

On  the  basis  of  information  gathered  in  the  report,  the  following 
conclusions  may  be  drawn:  (1)  Distributed  processing  systems  are 
not  vet  generally  available  as  off-the-shelf  items;  (2)  System 
software  development  of  minicomputers  lags  behind  their  hardware 
di'velopment — of  special  concern  is  the  apparent  lack  of  availability 
of  tested  multiprocessor  operating  systems;  (3)  Considerable  raw 
computing  power  is  available  from  minicomputers,  enough  to  handle 
the  FSS  functions;  (4)  Existing  minicomputer  software,  though  not 
as  powerful  as  that  available  on  large  mainframes , is  adequate  for 
writing  FSS  application  software;  (5)  Properly  designed  distributed 
mini-systems  with  good  hardware  have  potential  advantages  with 
respect  to  cost,  maintainability,  expansibility  and  flexibility; 

(h)  There  is  risk  in  using  minicomputers  for  the  FSS  application, 
but  tliere  appears  to  be  no  technical  reason  which  would  preclude 
implementing  such  a system;  (7)  Procurement  of  premium  grade 
hardware  is  essential  to  minimize  risk. 

Accordingly,  NflTRE  recommends  not  barring  distributed  mini-systems 
from  being  bid  for  the  FSS  modernization  program,  provided  that 
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adequate  safeguards  are  taken  to  ensure  procurement  of  high  quality 
liardware,  that  proper  testing  procedures  are  available  to  ensure  re- 
liable and  adequate  software  performance,  and  that  special  attention 


is  paid  to  securing  a good  multiprocessing  operating  system. 


(•(iNn.l'SldNS 


C'.ont'r.i] 

iU  St  r i but  fii  proci'SsiiiK  svstoins  of  thf  si^u  and  scope  required  by  Liu- 
FSS  jirojetl  are  not  vet  available  as  off-the-shelf  items,  nor  have 
anv  ol  till'  complexitv  envisioned  for  an  FSS  Hub  been  assembled. 
Howiver,  the  hardware  and  software  tethnoloy;y  exist  and  have  been 
assembled  into  a single  package  by  at  least  one  vendor.  Tlie  largest 

svstem  to  date  is  about  j9-b0%  of  the  estimated  size  of  an  FSS  Hub, 

but  does  not  handle  the  type  of  load  anticipated  for  the  FSS  (dynamic 
<iata  base,  r.tndom  demand,  real-time  operation,  etc.) 

The  distributed  processing  systems  assembled  thus  tar  have  largely 
been  custom  affairs,  optim.ized  for  the  unique  requirements  of  the 
partitular  application.  All  of  those  who  have  built  such  systems 

believe  in  the  future  of  the  concept,  so  long  as  too  much  is  not  de- 

manded of  the  distributed  system.  There  are  jobs  (as  explained  in 
Se.-tion  1)  which  are  not  suited  for  distributed  processing,  and 
there  appears  to  be  general  agreement  that  large  mainframes  with 
high  err  speeds  will  never  be  totally  replaced  by  distributed  systems. 

It  is  also  important  to  bear  in  mind  that  the  raw  power  of  today's 
premium  m.i  ni  computers  (e.g.,  UF.C  11/70,  DC  Eclipse)  surpasses  that  of 
second  gener.ition  m.ainframes  (e.g.,  IBM  7094)  and  approaches  that  of 


nanv  third  generation  machines  (e.g.,  IBM  360/65).  Indeed,  a bench- 
mark run  bv  f.eneral  Dynamics  suggest  that  in  some  respects  they  approach 
the  power  of  some  fourth  generation  machine. 

Infortunately  hcjwever,  software  development  for  the  minicomputers  has 
not  kept  pace  with  hardware  development,  and  while  real  time  multi- 
tasking operating  systems  are  available,  they  do  not  in  general  have 
the  variety  and  scope  of  support  packages  or  other  system  software, 
such  as  compilers,  offered  on  the  large  mainframes.  Typically,  real 
time  operating  systems  available  off-the-shelf  support  a single  pro- 
cessor and  interprocessor  communications  only,  and  with  the  exception 
of  TAN'DEM,  not  multiprocessing  in  the  broad  sense.  Some  operating 
system  software  development  will  probably  be  required  no  matter  which 
system  is  chosen. 

The  jobs  required  for  the  FSS  application  do  appear  to  be  within  the 
scope  of  present  day  minicomputers,  and  costwise  the  hardware  needed 
for  the  job  is  significantly  less  than  for  a comparably  powerful  main- 
frame. There  does  not  seem  to  be  any  reason  to  assume  that  minicom- 
puters could  not  handle  the  Flight  Service  Station  data  processing 
load  given  the  response  time  and  other  performance  parameters  as  set 
forth  in  the  specification. 
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S umrii.i ry  c t iU  .s  t r i hut  t'<i  T r(;('<‘.ss  i a;;  S vs  tom  Advant.iKes 
1.  ; nwer  cost  for  ociui  vjlont  cijmputinK  power. 

Potent  i.illv  hiRher  reliability  if  correct  system  architecture 
epploved,  and  pri‘mium  c,ualitv  hardware  used  throughout.  This  equip- 
rent  is  available  but  the  specification  must  be  verv  carefully 
written  ti  insure  its  procurement.  Reliability  is  something  which 
must  be  designed  into  a system,  and  cannot  be  tested,  patched  or 
rep. ii red  into  it. 

i.  Maintainability  can  be  facilitated  if  hardware  is  correctly 
designed,  i.e.,  is  very  modular.  This,  like  reliabilitv,  is  not 
an  .lutomatic  feature  of  distributed  systems. 

P.xpansibi  li  ty  of  mini-systems  is  a great  advantage  il  the  system 
software  and  overall  architecture  are  such  that  interprocessor  over- 
lu'.id  does  not  reduce  the  power  of  the  aggregate.  A well-designed 
r.ini-based  system  should  allo\y  for  considerable  expansion  capacity 
(on  the  order  of  lOOT  is  not  too  much  to  expect). 

5.  Flexibilitv  in  configuration  can  enable  the  FSS  Hub  to  cope  more 
easily  with  unanticipated  changes  in  service  requirements  and  demands. 


IX 


Siir;r,arv  of  Distributed  Processing  Disadvantages 

1.  Pi s t r 1 buttd  systems  of  the  size  and  scope  required  are  not  avail- 
able o t f- tlie-shel  f . 

2.  Automatic  reconfiguration  hardware  is  available  from  only  one 
vendor . 

3.  Benchmarking  a multiprocessor  system  will  be  difficult  if  part 
or  all  of  the  system  must  be  developed.  Benchmarking  efforts  up  to 
this  point  have  been  directed  toward  large  mainframes. 

A.  Data  recording  for  event  reconstruction  may  pose  some  problems 
in  a distributed  system  due  to  the  fact  that  all  the  information 
which  must  be  logged  may  not  be  available  on  one  machine.  Techniques 
such  as  combining  of  logging  tapes  off-line,  etc.,  will  probably 
tiave  to  be  employed.  These  problems  can  most  likely  be  overcome, 
but  will  require  special  software. 

5.  Lack  of  comprehensive,  well-debugged  software  support  packages, 
utility  programs,  and  compilers.  However,  these  features  are  avail- 
able in  varying  degrees  of  refinement  on  most  minicomputers. 

f).  Multiprocessor  Operating  Systems  are  not  generally  available 
of  f-the-shel f . 
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Kstinatt-  of  Risk  bv  Area 


Ttie  fTITUr/IAA  Study  Rroup  estimated  the  rlsl;  associated  with  dis- 
tributed proi-fss  iiiK  on  an  item-by-item  basis,  classifyinR  each  as 
low,  medium  or  hlRh.  This  Table  is  reproduced  as  Table  2. 

f'iiial  Conclusions 

The  conclusions  of  this  study  are  in  basic  agreement  with  those  of 
the  joint  >fITRE/FAA  Study  team. 

1.  Minicomputers  have  adequate  processing  power  to  handle  the  FSS 
application. 

2.  Distributed  processing  with  solid  hardware  and  good  system  archi- 
tecture has  advantages  over  mainframes  for  certain  types  of  jobs. 

3.  Software  requirements  of  the  FSS  system  pose  the  greatest  risk  at 
this  juncture.  Some  requirements,  such  as  automatic  reconfiguration, 
are  a risk  with  mainframes  as  well.  Though  progress  in  the  software 
area  is  difficult  to  predict,  distributed  processor  manufacturers  seem 
to  be  concentrating  on  developing  software  which  is  commensurate  in 
power  with  their  hardware,  and  many  risk  areas  identified  in  this  study 
may  be  eliminated  within  the  time  frame  of  the  FSS  procurement.  That, 
however,  cannot  be  guaranteed.  Further,  certain  software  (e.g.,  opera- 
ting system  for  real-time  multiprocessor  applications  and  reconf iguration) 
is  applicable  to  a relatively  snuall  segment  of  the  near-term  potential 
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TABLE  2 
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I 

I SIMMARY  OF  DISTRIBUTED  PROCESSINC  RISKS  BY  ARF:A 


RISK 


hardware:  hi  oh  medium  low 

STORAGE  (MEMORY  AND  DISC)  X 

SPEED  OF  PROCESSOR  X 

ERROR  DETECTION  X 

ERROR  CORRECTION  X 

SOFTWARE 

HIGHER  ORDER  LANGUAGES  X 

OPERATING  SYSTEM  SINGLE  PROCESSOR  X 

OPERATING  SYSTEMS  MLXTIPLE  PROCESSOR  X 
DE\TLOPMENT  TOOLS  X 


i 

SYSTEM 

PERIPHERAI  X 

ITiROUGHPUT  X 

AUTOMATIC  RECONFIGURATION  X 

COKI> ARABLE  SYSTEM  APPLICATION  X 


xll 


A 


il  I St  r i hilt  I’ll  prm  fss  i ii>',  ni.ir  kr  t p 1 ac  f , anil  as  a ri-siilt  mav  ri'iclvL- 


iittlf  lu-ar-tiTn  industry  attention. 

<•  The  wicii-  ran(<f  rl'  minicomputer  equipment  and  performance  dictates 
t!..it  a comprehensive  system  benchmark  he  performed  at  some  stage  in 
the  procurement. 

>.  rremium  itrade  hardware  (CPU  and  peripherals)  should  be  procured 
to  minimice  the  risks  associated  with  reliability,  performance, 
r..i  1 nt  .1  i nab  i 1 i t V and  schedule  problems.  Attempted  use  of  low 
qualitv  hardw.ire  could  result  in  catastrophic  increases  in  cost 
• ind  extremelv  poor  performance. 

ti . The  cost  for  a tvpical  Hub  system  can  be  expected  to  range  from 
about  S1.5M  to  S1.7.V  for  the  tvpe  of  configurations  considered  here, 
assuming  high  quality  hardware  used  throughout. 
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RKCOMMKNDATIONS 


On  t hi'  b.isis  of  the  an-ilysls  done  In  this  report,  and  the  informa- 
tion >;atlu'red  for  it,  the  following  recommendations  may  he  made: 

1.  Allow  distributed  minicomputer  systems  to  be  bid  for  the 
KSS  modernization  program,  but  make  special  provisions  for 
the  development  of  multiprocessing  operating  system. 

H . Write  the  specification  so  as  to  ensure  procurement  of 
high-grade  hardware. 

3.  Have  comprehensive  testing  and  benchmarking  procedures 
available  to  permit  proper  evaluation  of  systems  bid. 

With  respect  to  the  analysis  of  sample  configurations,  further 
work  should  be  done  to  refine  those  parameters  which  had  to  be 
estimated  in  order  to  carry  out  the  analysis. 
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Tho  t erm  'distributed  process  i iik ' todav  lias  many  meaniriKs  in 
the  data  proressiiiK  field,  rannine,  from  geographically  dispersed 
intelligent  terminals  to  colocated  tightly-coupled  multiple 
mini-  or  micro-computers.  In  this  report  a distributed  pro- 
lessing  system  is  considered  to  be  a looselv  coupled,  colocated 
set  of  minicomputers  iiientical  in  type,  with  all  peripherals 
necessary  to  perform  the  tasks  of  a Flight  Service  Station  Hub. 
ihe  purpose  of  the  study  is  to  analyze  the  feasibility  of  using 
such  a system  for  the  FSS  application,  with  particular  emphasis 
on  the  level  of  performance  that  can  be  expected  from  a properly 
designed  system,  the  degree  to  which  hardware  and  software 
essential  to  its  operation  are  commercially  available,  and  the 
I'verall  system  cost. 

1.1  Types  of  Distributed  Froccssing  Systems 

Distributed  processing  networks  may  be  divided  into  four  general 
categories : 

1.  Hierarchial,  consisting  of  a powerful  main  frame, 
fed  by  successively  less  powerful  smaller  machines, 
down  to  the  terminal  level,  with  each  job  ascending  in 
the  hierarrhv  only  as  far  as  necessary  to  obtain  the 
resources  it  needs  for  execution  (See  Figure  1-1). 
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J.  Star,  consisting  of  one  central  computer  (mini  or 
mainframe)  linked  in  radial  fashion  to  two  or  more  other 
computers,  which  are  controlled  by  it.  The  central 
machine  performs  all  scheduling  and  task  assignment 
functions,  and  may  in  addition  handle  a portion  of  the 
processing  load.  It  usually  has  all  or  most  of  the  data 
base.  (See  Figure  1-2.)  There  is  no  communication  be- 
tween satellite  machines  without  intervention  of  the 
central  computer. 

3.  Ring,  consisting  of  several  machines  linked  by  a 
one-way  circular  path,  along  which  all  messages  between 
machines  must  travel.  l/suaily  the  Individual  processors 
retain  a large  degree  of  autonomy.  (See  Figure  1-3.) 

4.  Global  Bus,  consisting  of  two  or  more  processors 
linked  by  a common  bus  line  which,  being  a node,  has  no 
directional  data  flow;  any  machine  can  communicate 
directly  with  any  other.  (See  Figure  1-4.)  The  Individual 
machines  are  usually  very  autonomous. 
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FIGURE  11 

HIERARCHICAL  NETWORK 


FIGURE  13 
RING  NETWORK 
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l.xamples  oi  tin-  latter  three  types  will  be  discussed  below  in 

Section  i.l.  No  hierarchial  systems  are  considered  here  be- 

★ 

cause  lar>;e  main  frames  are  excluded  from  this  study.  Hybrid 
types,  of  course,  also  exist. 

l.J  Uif  fcrences  Between  Distributed  Mini  Networks  and  Large 
Main  f_ranies 

The  reasons  for  employing  distributed  processing  configurations 
rather  than  large  main  frames  must  be  considered.  First,  with 
regard  to  throughput,  it  is  clear  that  m minicomputers  eacli 
capable  of  n instructions  per  second  will  collectively  be  able 
to  execute  nm  instructions  per  second.  If  the  minicomputers 
cost  less  than  one  large  main  frame  with  the  same  (nm)  raw 
computing  power,  cost  will  be  a reason  favoring  the  distributed 
coni igurat ion . But  merely  assembling  a group  of  minicomputers 
and  interconnecting  them  by  means  of  an  interprocessor  link 
will  not  necessarily  provide  the  same  task  throughput  as  the 
large  main  frame  regardless  of  the  raw  minicomputer  power 
available.  The  reason  is  quite  simple:  many  tasks  require 
serial  execution  of  a large  number  of  instructions,  and  cannot 
be  broken  down  into  tasks  running  in  parallel.  Clearly  feeding 

* For  a description  of  a hierarchial  network  employing  a ■)70/158, 
a F'DF  11/45,  and  several  smaller  machines,  see  *A  Hierarchical 
Network',  by  R.  L.  Ashenhurst  and  R.  H.  Vonderohe,  Da_t^amat_ion, 
Vol.  21,  No.  2 (February,  1975),  pp.  40ff. 
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siKti  .1  ’ol)  into  .1  >;roup  ot  mini's  will  result  in  one  bein^; 

• iss  i >',neii  the  job,  while  the  others  do  nothing.  Obviously  in 
this  . .is«>  the  l.ir^e  main  frame,  with  Its  higher  exeiution  rate, 
will  lomplete  the  jfih  mie  h faster.  However,  in  the  case  c'f 
siiort  run-time,  I/O  bound  jobs,  which  do  lend  themselve.s  to 
proressin^t  in  separate  machines,  the  mini  system  could  be  as 
last  or  possibly  faster  than  the  large  main  frame,  which  would 
have  to  handle  the  jobs  using  a time-slicing  algorithm  or  pre- 
emptive-resume queuing  scheme.  The  time  required  to  complete  a 
task,  however,  will  depend  on  I/O  bandwidth,  operating  system 
design,  load,  queuing,  etc.  But  insofar  as  the  task  load  consists 
ot  short  run-time  jobs,  especially  I/O  bound,  the  distributed 
mini  architecture  is  a candidate  for  replacement  of  a large  main- 
frame if  there  is  a significant  cost  difference,  which  there 
often  is. 


This  situation  has  been  recognized  by  designers  and  proponents 
ot  multi-mini  systems.  Dr.  William  Wulf,  whose  system  is  dis- 
cussed in  Section  3.1.1,  says: 

By  now  the  data  processing  community  has  become 
sophisticated  enough  to  understand  that  there 
are  no  p.inatt*as.  Thus,  although  there  are  manv 
adv.antages  to  multiple  mini-computer  systems, 
such  systems  are  not  Ideal  for  all  applications 
.ind  they  pose  new  problems  which  must  be  solved 
if  these  new  architectures  are  to  realize  their 
full  potential. 
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I’erh.ip!^  tho  most  obvious  .ipp  1 i i u t ii'os  for 
whii'h  the  multi-minis  nro  ill-suitcii  art*  the 
lar>>e  "number  irunehin^i"  ones,  involving  a 
great  deal  of  1 1 oat  ing,-po  i nt  arithmetic. 

Minis,  multi  or  not,  frequently  do  not  have 
floating-point  hardware,  and  even  those  that 
do  are  cons  t r.i  i ned  by  their  sm.all  word  size 
to  implement  such  operations  as  slow,  multiple 
memory  reference  instructions.  They  therefore 
fall  sh(’rt  of  large  scientific  processors  both 
in  basic  ,pu  speed  (by  a factor  of  2-5)  and 
memory  bandwidth  (by  a factor  iif  2-8),  and 
these  factors  may  go  much  higher  for  specific 
machines  (like  CDf.’  .STAR's  pipelined  floating- 
point processor  or  the  IBM  3bO/85  with  its 
i-ache  memory).  However,  commercial  data  pro- 
essing  appliiations  f.ill  well  within  the 
mini's  range  of  practical  utility,  since  it  is 
intended  to  perform  byte  manipulation  and  T/0 
with  considerable  efficiency... 

Obviously,  bit  rates  do  not  tell  the  wtiolo  story. 
In  exchange  tor  the  speed  inherent  in  parallel 
processing,  the  user  receives  the  problem  of 
task-decompos i t ion  — that  is,  the  subdivision  of 
an  application  program  into  pieces  which  can 
be  executetl  in  parallel  and  therby  fully  use  the 
power  aviiilable  in  the  system.  Fortunately  for 
the  user,  he  is  not  required  to  solve  this  pro- 
blem at  the  outset;  he  can  choose  to  build  his 
program  initially  in  the  t r.id  i t iona  1 , sequential 
way  and  rework  it  later.  Obviously,  his  initial 
program  will  not  run  faster,  but  the  system  can 
still  execute  16  such  "temporarily  sequential" 
programs  in  parallel,  with  no  real  loss  in 
throughput  over  a mul 1 1 programmed  uniprocessor 
or  batch  system.  Kventually,  as  the  user  de- 
signs an  effective  parallel  decomposition,  he 
can  rebuilc'  his  program  to  reap  the  benefits  of 
the  architecture.  * 


iam  Wulf  and  Rov  I.evin,  'A  I.ocal  Network',  DatamiUion,  Vol.  21, 
2 (February,  1475),  pp.  49. 
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S.ditui,  a distributed  architecture  may  lend  itself  to  more 
modu:..r  implementation  of  functions,  thereby  effecting  a poten- 
tial Increase  in  reliabilitv  if  the  operating  system  is  capable 
■ dete>.tiny,  failures  and  initiatinR  automatic  reconfiguration. 
The  required  redundancy  is  much  less  expensive  than  in  the  case 
of  a lar^te  mainframe  (which  would  necessitate  duplication  ot  a 
ven.-  costly  CPU),  and  may  in  addition  provide  a degree  of  pro- 
tection against  multiple  failures.  It  is  important  to  note, 
iii'wever,  tl;at  without  proper  hardware  and  proper  system  archi- 
tecture, and  in  particular  without  some  type  of  automatic  re- 
configuration, the  distributed  mini  system  could  have  a higiier 
failure  rate  and  lower  availability  due  to  a larger  number  of 
sin>’.le  points  of  failure.  Distributed  processing  does  not 
guarantee  higher  reliability. 

Finally,  Auerbach's  general  comment  on  the  state-of-the-art  in 

computer  networking  is  interesting: 

An  analysis  of  the  literature  of  networking,  such 
as  that  made  by  Al'F.RBACH  while  developing  its  new 
multivolume  looseleaf  subscription  service,  "Dis- 
tributed Systems,"  reveals  that  while 

- Most  networks  in  use  now  are  hierarchical, 

- The  literature  on  networks  is  predominantly 
about  distributed  networks. 
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U'h.it  explains  this  apparent  dicliotomv?  The  answer 
is  that  h ier.iri  h i I a 1 networks  can  t)e  built  today 
with  off-the-shelf  products  from  the  major  main 
frame  manufacturers.  Distrii)uted  networks  cannot. 

Thev  arc  on  1 v supported  by  minicomputer  manufactur- 
ers like  liewlett-i’ackard  .ind  Digital  (although 
Digital's  DIKINKT  cannot  yet  be  fullv  implemented). 

K'rr)m  the  l.argo  scale  gener.i  1 -purpose  computer  point 
ot  view,  distributed  networks  remain  the  stufi  of 
advanced  computer  science  courses  and  the  province 
of  DP  buffs  with  large  ideas  and  larger  budgets, 
hierarchical  networks  are  highly  utilitarian,  con- 
cerned with  fueling  the  engines  of  everyday  commerce.* 

Nevertheless,  research  conducted  for  this  report  indicates  that 

the  situation  today  is  rapidly  changing,  and  overall  the  picture 

is  considerably  brighter  for  certain  applications  of  distributed 

processing.  The  Flight  Service  Station  does  appear  to  be  one 

which  can  be  adapted  to  a distributed  architecture,  and  two 

sample  configurations  are  analyzed  in  detail  below.  Section  4. 


* Auerbach  Computer  Technology  Reports,  Sec.  OSO . 0000 . T05 , 'Network 
Design:  Introduction  to  Computer  Networks',  pp.  3. 
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-k  tikYL'i  ’ ^ 

The  miiximum  load  for  .in  FSS  Hub  is  summarized  in  Appendix  A; 
the  functions,  number  of  machine  instructions,  iind  disk 
accesses  for  each  are  summarized  in  Appendix  B. 

The  FSS  baseline  system  function  specification  also  requires 
fail-safe  operation,  which  is  defined  as  follows: 

1.  Krror  detection  by  the  computer  program. 

2.  Krror  isolation  by  the  computer  program. 

3.  Switching  of  the  failed  unit  out  of  the  system 
by  the  computer  program  to  effect  isolation  of  the 
failed  unit. 

4.  Switching  of  a redundant  unit  into  the  system 
by  the  computer  program  to  replace  the  failed  unit. 

5.  Automatic  resumption  of  operation. 

There  are  various  other  general  requirements  concerning  main- 
tainability and  reliability  which  should  also  be  met  by  any 
distributed  processing  system. 

Based  on  the  above  and  other  considerations,  the  desirable 
features  for  a distributed  system  architecture  are  listed 
and  discussed  below. 
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. . 1 il.irdwnre 
.’.1.1  Monc'rv 

Hotli  memc'rv  size  ;ind  lvp<?  will  be  critical  in  deternilnin)^  the 
IHTlormance  of  anv  distributed  computing  system.  Important 
features  are  as  follows. 


J . 1 . 1 . 1 _iiapacj  t_y 

riie  .mount  of  men.orv  reciuired  per  machine  will  vary  with 
svstem  archi tecture,  hut  based  on  previous  estimates  and 
on  tile  e.xperimental  system  at  .'ili'RK,  at  least  25f)K  In'tes  per 
m.i.hine  will  be  required,  and  for  certain  configurations  up  to 
IM  nav  be  needed  when  allowance  is  made  for  reserve  and  ex- 
pans  ion . 


J.1.1..J  Type 

•Miiiougii  eiilier  major  type  of  memory  (core  or  semiconductor) 
will  tunction,  semiconductor  has  some  potential  advantages 
in  lower  dissipation,  less  space  required,  and  in  future  years, 
lower  rijst. 


J^l  i_ jjr rjpr  Detection 

clo.irlv  .1  desirable  feature  for  fail-safe  and/or  fall-soft 
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oporatlon  1h  error  detection  In  tVie  memory.  This  is,  in  fact, 
•tlmost  indlspensi hie  for  reliable  operation. 


2. 1.1.4  Error  Correction 

A step  beyond  error  detection,  this  feature  permits  the  memory 
to  correct  single  bit  errors  and  continue  operating  with  no 
system  degradation.  By  reducing  failures  that  require  immediate 
maintenance  action  it  improves  system  availability. 


2.  1.1. 5 Type  of  Addressing 

Memory  may  be  addressed  either  directly  using  a fixed  number  of 
bits  containing  the  binary  address,  or  using  two  groups  of  bits, 
one  being  the  direct  address  within  a small  area  of  memory, 
usually  a page,  and  the  other  group  a number  reference  to  an 
entry  in  a table  (called  the  'map')  containing  the  physical 
starting  address  of  the  page.  There  are  potential  advantages  to 
a mapped  system  in  that  mapping  permits  dynamic  reallocation 
around  failed  memory  space. 


2.1.2  Multiprocessing 

Since  any  distributed  system  must  be  capable  of  interprocessor 
comuni cat  i on , there  is  a requirement  for  hardware  to  provide 
for  high  speed  communications  between  processors.  This  hard- 
ware should  permit  DMA  transfers  of  at  least  lOOK  bytes/second 
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S 1 ML r inori'  th.m  twL'  processors  will  likely  be  Involved,  the 

irdw.jre  shonlii  not  he  of  such  type  that  if  one  processor  fails, 

. inrx^unicat  ii'»ns  between  other  processors  are  impaired. 

. 1 . ) k»'i  enl  ij^iirat  ion 

<in.  e re.  onf  i v’ur.it  ion  is  a system  requirement,  clearly  any  com- 
puters selecteil  mvist  either  offer  it  off-the-shelf,  or  it  will 
h.t'.'e  to  be  lieveloped.  Since  development  of  such  a capability, 

‘oth  har.iware-  .in<i  sof  tware-wise,  is  likely  to  be  difficult 
inii  lostlv,  tills  is  ,1  particularly  desirable  feature  to  have 
.r.  a liable  as  ,i  standard  item. 

b . 1 . ■*  Mai  ii_incj_  _Spt^ed 

"iiis  is  not  strii  tlv  speakitiR  a teature  as  much  as  > liaractcris- 
lii  ol  all  maihini's,  and  clearly  for  the  FSS  application,  tlie 
hiKher  the  speed  the  better  the  machine,  other  things  being 
equal.  ilowever,  machines  which  look  the  same  on  paper,  i.e., 
wiiose  average  instructions  execution  rates  based  on  some 
.tandari  mix  art'  equal,  may  due  to  onerating  system  or  compiler 
infill'  ieniies  turn  out  to  be  radically  different  in  actual 
performance.  As  an  example,  a benchmark  run  by  General  Dynamics 
on  a group  of  machines,  including  several  under  consideration 
lor  this  project,  showed  that  two  of  them,  nearly  equal  on 
paper,  differed  bv  a factor  of  30  in  time  to  execute  tlie  test 
program.  Hence,  this  cliarac ter ist  ic  must  be  regarded  with  caution. 
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Sol  tw.irt.' 


. 2 . \ Mull  i^’roc  1 

Since  any  disiributed  proi't'ssing  svstem  by  definition  involves 
some  degree  of  multiprocessing,  it  is  desirable  to  have  system 
suitware  available  from  the  vendor  which  supports  mul t iprocessing 
to  the  maximum  degree  possible,  for  example  some  dynamic  alloca- 
tion of  system  resources. 

2 . 2 .2_  Languages 

(liven  that  the  FSS  programs  are  to  be  written  in  a higher  level 
language,  it  is  most  desirable  that  one  or  more  standard 
languages  be  available  on  the  machine  selected,  powerful  enough 
to  handle  both  numeric  calculations  and  alphanumeric  (string) 
manipulations.  Development  and  debugging  of  compilers  is  ex- 
pensive and  time  consuming,  and  should  be  avoided  if  at  all 
possible. 

2.2  . i AuUmatlc  Rc^conl  i^urat  i_ti^n 

I'his  feature  is  taken  in  conjunction  with  hardware  required 
to  implement  it,  and  the  same  remarks  apply. 
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■ 4 Comnuini  f.i  t i ons  So[  twa  rc 

This  parkaRo  wtnild  bt-  useful  for  communicat  ions  with  tlu'  outside 
world,  but  given  the  special  nature  of  front  end  (terminals)  and 
hack  end  (N’ADIN)  communication  of  the  FSS , special  application 
programs  mav  have  to  be  written  anyway. 

d . ? . 1 Da ta  Base  Management  System 

Most  DBMS ' s are  intended  for  applications  such  as  on-line  inven- 
torv  control,  and  their  usefulness  for  the  FSS  application  may 
depend  on  the  DBMS's  flexibility  and  overhead  cost.  This  study 
.issumes  that  a special  type  of  data  base  management  for  weather 
data  will  be  emploved.  DBMS's  are  only  now  becoming  available 
on  minicomputers  and  their  reliability  may  not  be  adequate,  or 
at  least  demonstrable.  If  sufficiently  flexible  and  reliable, 
however,  and  without  a high  penalty  in  overhead,  a DBMS  could 
be  most  useful  in  handling  part  of  the  FSS  data  base. 

J.i  Survey  of  Minicomputers  Deemed  Suitable  for  the  FSS 
Application  and  Their  Features 

Table  2-1  is  intended  to  be  a representative  though  not  exhaus- 
tive survey  oi  minicomputers  available  for  possible  use  in  a 
distributed  processing  configuration  for  the  FSS  program.  In- 
cluded in  the  table  are  the  features  discussed  above  which  are 
deemed  important  to  the  FSS  application.  Information  was  taken 
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! ri'ir  Auorhach  Ki-ports,  Datapro  Reports,  aiui  veinlor  documentat  loti 
■..lilt  .1  v.i  i 1 all  1 1' . !t  Is  ht'lli-ved  to  be  .iccura  I *•  but  may  not  in 
■ ill  ( usi'S  bu  l■<lm)l  1 1' t (■  1 V up- 1 o-da  t f . Tht'ru  1h  no  Implication 
that  MiIHl'  iudp.i’s  tht'so  machines  to  be  the  only  ones  suitable 
for  the  KSS  application. 

rhere  are  a few  points  to  be  made  with  respect  to  the  features 
listed.  First,  no  machines  having  less  that  256K  bytes  of 
memory  capacity  were  considered,  since  this,  in  MITRK's  opinion, 
is  the  absolute  minimum  for  any  likely  FSS  distributed  configura- 
tion. Most  vendors  offer  optional  battery  supplies  to  save 
er.il  onductor  memory  in  the  event  of  a power  failure. 

Multi  processing  was  considered  to  be  software  supported  only 
i!  the  operating  system  viewed  the  entire  network  as  an  avail- 
able resource,  and  had  a comprehensive  scheduling  algorithm 
for  allocating  system  resources  as  needed.  Simple  recognition 
i)v  the  operating  system  of  other  computers  was  not  considered 
to  be  software  support,  though  the  higher  lever  of  multipro- 
cessing may  not  be  required  for  the  FSS. 

ihe  liii’.her  order  languages  listed  are  those  claimed  bv  the  ven- 
dor. Only  'universal'  languages  were  considered;  vendor 
designed  languages  are  not  included. 


2-d 


Kci  ont  i >’ui  .U  inn  wns  nniis  i dcrod  to  ho  av.iilnblf  if  wli.it  the 
\end<'t  ilninied  w.is  approximately  what  has  been  defined  as 
.iutom.it  i(  reoon  t i >tii  ra  t i on  for  tfie  F.SS.  If  the  vendor  i laimed 
sc’me  reasonable  subset  of  the  features  'limited'  was  placed  in 
the  column  entry. 

Ttie  mactiine  speed  Riven  is  approximate  onlv,  based  on  the 
tol lowing  instruction  mix  (when  information  available). 


l.oad/store 

15% 

Fixed  add 

25% 

Logical  AND 

2 5% 

Shift 

15% 

F loat ing  Pt . 

Add 

10% 

1 1 1 1 

Multiply 

5% 

i>  It 

Divide 

5% 

This  information  is  Intended  only  as  a rough  guide,  and  should 
not  be  used  to  judge  the  various  machines.  An  accurate  measure 
of  machine  speed  will  require  a benchmark. 

Ttie  final  two  columns,  again,  were  completed  based  on  vendor 
informat i<in,  no  independent  verification  of  these  software 
packages  is  available. 
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KXISTINC  UISTRIIU'TKI)  PKOCKSSINC.  SYSTEMS 


Ak  part  of  tiif  < ff(>it  to  tiotormino  tht  foasihility  of  distrl- 
butfd  proct'ssinp,  as  .ippl  ted  to  ttie  t SS  system,  visits  were  made 
to  several  sites  whlcli  liave  a reputation  for  ploneerinp,  this 
field.  Reports  on  several  others  were  obt.ilned,  all  with  a 
view  to  learning  their  problems  and  obtaining  recommendations 
from,  them  concerning  distributed  processing  in  general.  Part 
of  this  effort  was  directed  to  learning  whether  any  existing 
sites  are  of  a complexity  comparable  to  tiiat  anticipated  for 
the  FSS  system. 

The  installations/sites  visited  or  researched  were  as  follows: 


Non-FAA  FAA 

Citibank,  Mew  York  DARC 

Southern  Bell,  Atlanta  DABS 

Carnegie-Mellon,  Pittsburgh  ARTS  III-A 

Bell  Labs  'Spider',  Murray  Hill,  New  Jersey  AWANS 


JFTS,  Ottawa,  Canada 

MITRE  MTI  System,  Bedford 

Kansas  State  University 

DCS,  University  of  California,  Irvine 

Carter  Associates,  Cupertino,  California 

MITRE  TICCIT  System 

ARPA  Network 
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t.l  Di'hc  r l^t  iDHh  nl  inn!  i)  1 l.il  Ions  Ics 
t.  I . i < 1 1.  I I'.ink  , 

I'liis  is  onr  of  ttu'  itioro  wldclv  l<ti<’wn  li  1 st  r i Init  od  proicsslnv, 
systems.  Citibank's  application  is  a stock  transaction  system 
and  mini's  were  chosen  specifically  to  replace  IBM-3bO's.  ll\e 
following’  points  relevant  to  the  FSS  application  mav  be  made 
with  respect  to  this  system. 

1.  It  is  a load  sharing  configuration. 

2.  Split  is  along  organizational  rather  than  functional 
lines. 

1.  Response  time  is  3-1  secomls,  but  not  deemed  critical. 

•1.  There  are  several  identical  systems,  and  the  contigura- 
tion  of  each  consists  of  two  Interdata  8/32  minis  and  2 to  b 
300  megabyte  drives  at  each  location;  one  computer  on  line; 
other  switched  in  manually  if  first  fails. 

5.  N'o  auto  reconfiguration. 

6.  No  interprocessor  communication. 

7.  No  remote  terminals. 

8.  Any  Intermachine  transfers,  e.g.,  new  programs,  are 
handled  by  physically  carrying  a tape. 

9.  An  important  factor  in  the  ciioice  of  Interdata  was  its 
similarity  to  IBM  with  respect  to  programming.  There  was 
also  a minimal  benchmark  performed  on  several  machines, 
which  consisted  of  determining  if  and  how  fast  each  could 
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run  scnni-  s.inpl»-  COBOL  proKr.ir.s  In  use  at  the*  time  on  Citi- 
bank's ibO's. 

10.  Only  t i mi’  requirement  is  72  hour  SEC  regulation  on 
turnaround;  it  one  system  fails  completely,  work  can  be 
done  on  another;  all  systems  in  same  building. 

There  was  general  agreement  am.ong  those  present  at  the  brief- 
ing that  this  application  is  too  dissimilar  to  the  FSS  system 
to  perm, it  anv  inference  about  the  feasibility  of  using  mini- 
computers for  the  FS.S  job. 

i.l.J  .Southern  Bell,  Atlanta 

The  minicomputer  system,  installed  by  Southern  Bell  in  Atlanta, 
however,  is  more  closely  related  to  the  FSS  application. 

Liven  in  Figures  3-1  and  3-2  is  a block  diagram  of  the  configura- 
tion, and  in  Tables  3-1  and  3-2  a summary  of  system  downtime 
and  availabil itv. 

The  purpose  of  this  system  is  to  permit  requests  for  service, 
repairs,  installation,  etc.,  to  be  entered  from  remote  terminals 
spread  over  a wide  geographical  area.  The  requests  are  then 
processed  by  the  system,  which  makes  up  work  orders  to  be  re- 
leased at  Che  appropriate  time,  and  handles  all  accounting 
functions  and  record  keeping  associated  with  the  job. 


3-3 


Till’  svsten  Joes  not  have  automatic  reconf  ij<urat  ion , but  in  tiie 
event  ot  a failure  in  either  the  disk  processor  or  the  front 
end  processor,  I’l  or  P2  can  be  manually  switched  in  fby  means 
of  a bus  switch)  to  assume  the  load  of  the  failerl  processor. 
System  up  time  is  summarized  in  Tables  3-1  and  3-2  and  as  can 
be  seen  is  quite  good.  According  to  Southern  Bell,  most  of 
the  down  time  is  due  to  maintenance  difficulties  rather  than 
inherent  hardware  or  software  problems. 

The  system  functions  as  follows: 

1.  Service  order  tvped  in,  entries  checked  for  correctness. 

2.  Completed  entry  sent  to  disk  processor,  where  it  is 
logged . 

1.  Order  then  relayed  to  PI  or  P2  processor,  sent  to 
distribution,  held  for  acknowledgment  of  completion  (up 
to  one  week) . 

A.  Wlien  job  done,  completion  message  typed  in,  information 
rel.ived  to  all  other  parts  of  system. 

Each  com.puter  has  its  own  operating  system,  but  all  are  basical  Iv 
slaved  to  the  disk  processor.  The  interprocessor  channel  was 
DEC  equipment,  modified  by  Formation  Inc.,  the  systems  house 
which  assembled  the  hardware  for  Southern  Bell.  The  front  end 
can  handle  up  to  240  terminals,  though  presently  the  maximum 
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TABLE  3-1 


SOUTHERN  BELL  DATA  SYSTEM 
DOWNTIME  SUTIMARY  FOR  19  76 

08:00  - 1800 


% UPTIME 

08:00-18:00 

8 SITES 

10  SITES 

JANUARY 

97.6% 

98.0% 

FEBRUARY 

97.1% 

9 7.6% 

MARCH 

95.8% 

96.3% 

APRIL 

98.6% 

98.9% 

MAY 

98.0% 

98.4% 

JUNE 

98.2% 

98.6% 

JULY 

97.8% 

98.3% 

AUGUST 

97.8% 

98.2% 

SEPTEMBER 

98.5% 

98.8% 

OCTOBER 

98.5% 

98 . 8% 

NOVEMBER 

97.5% 

98 . 0% 

DECEMBER 

98.4% 

98.7% 

1976  TOTAL 

97.8% 

98.2% 

OBJECTIVE 

99.4% 

99 . 6% 

3- 


TABLE  3-2 


SOUTHERN  BELL  DATA  SYSTEM 
IX)WTIMI-:  SITIMARY  FOR  19  76 
00:00  - 24:00 


% UPTIME 

0 
o, 

1 : 
O' 

o 

o 

o 

8 SITES 

10  SITE 

lAM'ARY 

98.4% 

98.7% 

FEBRUARY 

98.4% 

98.7% 

M/\RCH 

97.4% 

97.7% 

APRIL 

98.7% 

98.8% 

M/\Y 

98.9% 

9^ . 2% 

JUNE 

98 . 8% 

99.0% 

lULY 

98.2% 

98.6% 

AUOIIST 

98.5% 

98.8% 

SEPTEMBER 

99.0% 

99.2% 

OCTOBER 

98.8% 

98.9% 

NOVEMBER 

98.7% 

98.9% 

DECEMBER 

98.2% 

98.6% 

1976  TOTAL 

98.5% 

98 . 7% 

OBJECTIVE 

99.8% 

99.8% 
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connected  at  anv  Installation  Is  115.  Any  response  times  over 
five  seconds  are  considered  poor;  957  of  the  responses  are  less 
than  10  seconds  but  some  take  as  long  as  90  seconds. 

The  operating  system  (exclusive  of  applications  programs)  was 
written  in  an  assembly  language  developed  by  .Southern  Bell,  and 
was  operational  in  18  months;  but  total  development  effort  in- 
volved seven  programmers  for  three  to  four  years.  The  fact  that 
the  operating  system  was  written  in  assembly  language  is  appar- 
ently causing  some  problems;  at  present  more  core  would  help 
throughput  and  response  time  but  would  require  major  operating 
systems  changes  for  support. 

The  system  is  similar  to  that  envisioned  for  the  KSS  in  that  it 
is  real-time,  multiprocessor,  reconf Igurable , checks  input, 
holds  data  for  completion  messages  to  be  input  later,  and  sup- 
ports a large  number  of  interactive  terminals.  It  differs  in 
that  large  volumes  of  data  are  not  output  to  the  entering 
position,  response  time  is  not  regarded  as  quite  so  critical, 
and  the  data  base  is  not  being  continuously  updated. 

3.1.3  Carnegie  Mellon  University  - C.mmp,  Pittsburgh 

This  installation  was  visited  by  a team  from  MITRE  and  the  FAA, 

and  described  in  an  article  in  Datamation,  February  1975, 
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PK.  •^7-^0.  C.minp  Is  an  abbreviation  for  Carnenle-Mel  1 on 


Multi-Mini  Processor. 


The  system  consists  of  16  processors  and  16  memorv  boxes, 

Interconnected  by  a switch  which  is  the  central  component  of 

the  system.  According  to  Professor  William  Wolf; 

This  switch  allows  any  of  the  processors  to  access 
any  of  the  memory  boxes  on  each  memory  reference.  The 
processors  are  not  permanently  attached  to  a memorv 
box,  rather,  each  time  a processor  wishes  tci  access 
a particular  memory,  a temporary  connection  is  estab- 
lished through  the  switch  for  that  access.  Sixteen 
separate  processor-memory  connections  are  possible 
simultaneously.  Thus,  unless  two  processors  are 
attempting  to  access  the  same  mem.ory,  16  separate  and 
simultaneous  communication  paths  exist  between  pro- 
cessors and  memory.* 

A diagram  of  the  system  is  shown  in  Figure  3-3. 


The  system  can  be  configured  into  several  smaller,  independent 
systems;  and  this  partitioning  enables  a type  of  fail-soft 
stjftware  architecture  to  be  implemented,  so  that  the  system 
ilegrades  gracefully  in  the  event  of  a CPF  or  memory  module 
failure.  An  offending  unit  is  'partitioned  out'  for  maintenance, 
and  the  rest  of  the  system  continues  to  run;  but  there  is 
apparently  no  way  of  assuring  that  a malfunctioning  processor 
cannot  contaminate  all  of  memory;  nor  is  there  automatic  detec- 
tion of  errors.  Also,  because  the  system  has  several  potential 
* Dp.  Cit  p.  47 
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sin>;li'  points  of  f.-iiliirf"  (o.j;.,  tlto  switih  ninl  t lio  intorrupt 
;>us) , it  would  bo  vorv  diflicult  to  mako  fail-safe. 


'.be  (.mir.p  n.iturallv  lias  .i  eus  t ori-wr  1 1 1 on  ope  ra  1 1 n>’,- 1 ype  systoin 
0.1  lied  .1  'kern.il',  designed  to  provide  maxinaim  flexibilitv  in 
t'r.e  use  of  svsteir  resources.  For  the  FSS  application  it  is 
prob.iblv  r.uch  too  close  to  the  hardware  to  be  practical.  There 
i;;  no  job  control  lan^;uaKe,  and  the  overall  systeir.  is  not  t rans- 
p.iron!  eiioiiKli  to  be  safe  for  or  useful  to  the  .iver.ige  progr.ir- 
r-.er . 


I he  authors,  moreover,  appear  to  have  overlooked  an  important  tact 
’ in  queueing  theory.  They  say  with  .'egard  to  response  time: 


A multiprocessor  with,  say,  16  processors,  can  provide 
better  real-time  responses  than  a single  processor  wiiich 
is  16  times  as  fast.  Fven  though  it  clearly  takes  longer 
to  service  each  individual  real-time  event,  service 
for  an  event  can  usually  begin  immediately  in  i multi- 
processor system,  since  more  than  one  processor  is 
available  to  respond  to  the  (high  priori  tv)  request  tor 
real-time  service.* 

'iNdiat  is  involved  here  is  the  so-called  'scaling  effect',  which 
is  tile  effect  on  response  time  of  replacing  one  mactiine  operating 
at  m instructions  per  second  with  n machines  operating  at  m/n 


* 


P- 


A9 
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instructions  per  second.  As  It  turns  out,  not  only  do  re- 
sponse tine  and  queueing  time  not  go  down,  or  even  remain  tiie 
same,  they  in  fact  go  up  by  a factor  of  n.* 

So  the  merits  of  this  or  anv  distributed  processing  system 
with  respect  to  response  time  must  be  evaluated  by  a careful 
application  of  queueing  tiieorv’  to  the  particular  design. 


Overall,  the  C.mmp  System  is  interesting,  but  there  are  major 
differences  between  this  applii:ation  and  the  FSS  program  as 
current  Iv  envisioned. 


Witii  respect  to  distributed  mini-systems  in  general,  br . Wulf 
discussed  iiis  experience  with  the  MITRE/F/\A  study  team  which 
visited  his  site,  and  following  is  a quotation  from  their  final 
report : 

Dr.  Wulf  indicated  ttie  following  risks  concerned  with 
minicomputer  distributed  networks:  no  off-the-shelf 
operating  system  exists  today,  but  the  expertise  is 
available;  the  need  for  a high-order  language...;  pro- 
ficient data  base  management  programs  are  not  avail- 
able; a floating  point  estimate  of  20%  may  form  the 
need  for  a 32-bit  word  machine;  using  mapping  tech- 
niques in  lb-bit  machines  may  reduce  efficiency  by 
30%;  lace  recording  of  transient  errors  upon  task 
comjiletlon  was  the  biggest  problem  encountered; 


* A.  0.  Allen,  'Elements  of  Queueing  Theory  for  System  Design,' 
IBM  Systems  Journal,  No.  2,  (1975),  p.  167. 
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and  functional  program  assignment  to  processors  does  not 
provide  the  best  efficiency  In  a reduced  mode  of  operation. 

i ■ 1 . '4  Hell  Labs  'Spider',  Murray  Hill,  New  Jersey 
'Spider'  is  a small  packet-switched  data  communications  system, 
designed  to  link  a number  (currently  11)  of  computers.  The  link 
IS  accomplished  through  a Terminal  Interface  Unit  (TIU)  at  each 
computer,  all  of  which  In  turn  are  connected  by  a high  speeti 
line  to  a com.puter  functioning  as  a switch  (see  Figure  3-4). 

The  purpose  of  this  system  is  to  interconnect  the  different  types 
of  cor.puters  being  used  at  the  Bell  Labs  facility,  so  as  to 
provide  better  service  to  the  users  of  the  individual  machines 
by  allowing  them  to  take  advantage  of  the  computing  power  availa- 
ble on  other  machines.  The  unique  feature  of  this  system  is 
its  'Virtual  Channel',  whereby  computers  appear  to  be  directlv 
linked  to  each  other  while  conversing,  even  though  no  assignment 
of  physical  equipment  is  made,  and  the  machines  mav  be  operating 
at  quite  different  rates.  The  heart  of  Che  virtual  channel  is 
the  mdcroprocessor  based  TIL',  which  replaces  modems  and  data 
sets  and  permits  handling  of  64  full  duplex  data  transmissions 
at  one  time.  As  Dr.  Fraser,  the  system  designer  describes  it; 

This  means  that  the  PDP-11/45  shared  file  svstero, 
for  example,  can  carry  on  simultaneous  conversa- 
tions with  several  other  computers  even  though  it 
has  only  one  TIU.  In  addition,  the  TIU  provides 
buffering  for  one  packet  of  data  on  each  of  its 
input  and  output  paths.  This  allows  terminal  1/0 
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FIGURE  34 

LABORATORIES  'SPIDER'  NETWORK 


oj)fr.i  t il'tis  til  proLfeJ  iisvnrhfoiiovisl  y <it  .my  spoi'il 
up  to  the  mdximun  the  network  c.in  h.indle,  <ind  the 
TIi'  ran  ret  r.tnstni  t the  p.icket  autom.itical  ly  when 
t ransr.lssiori  error  ruikes  that  necessary.* 

Since  ttie  Spicier  network  is  not  designed  prln-uirily  as  a dls- 
tnhiited  processing  systen,  but  .as  .a  computer-to-computer 
corx.uni cat  ions  systen,  its  primary  relevance  to  the  FSS  proRr.an 
is  in  the  area  of  intercomputer  communication,  in  that  it  demon- 
strates one  t lexible,  low  overhead  technique  tor  linking  a 
'..trge  number  caf  machines. 


3.1.5  JETS,  Ott.iwa,  Canada 

'JETS'  is  an  acron>-m  for  .loint  Enroute/Termlnal  System,  and  is 
intended  to  gatiier  and  process  radar  data  on  air  traffic,  for 
presentation  to  controllers  on  display  equipment. 


A j'ETS  installation  consists  of  two  central  processors  (one 
on-line,  one  hot  standby),  one  tracking  processor,  one  system 
control  processor,  and  vip  to  32  display  processors,  each  con- 
trolling one  display  (see  Figure  3-5). 


* Ur.  A.  (i.  Fraser,  'A  Virtual  Channel  Network',  Datamation , Vol. 
21,  No.  2,  (February  1975),  p.  52. 
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I hf  nacliiiu's  in  the  system  are  Interdata  model  70.  1 hev  weri' 

not  chosen  per  se . hut  the  Contractor  wlio  received  the  aw.ird 
chose  th.er..  There  was  some  question  at  the  time  about  the 
advisability  of  this  selection,  which  appeared  to  be  b.eavi  ly 
influenced  bv  price;  and  indeed  it  led  to  problems  later. 

At  the  time  the  project  was  undertaken,  there  was  a desire  to 
stimulate  domestic  industrv’  and  for  this  reason,  as  well  as  (or 
re.isons  of  reliability  and  cost,  the  procurement  was  restricted 
to  minicomputers.  Discussions  on  the  project  began  in  1971, 
the  contract  was  awarded  in  1973,  and  the  first  system  due  in 
1975.  Presently  delivery  of  the  first  system  is  expected  in 
Septen.ber  of  this  year. 

The  main  problem  with  the  system  up  to  now  has,  of  course,  been 
the  delays  involved  with  it.  There  are  several  reasons  for 
tlu'se  delays,  the  Canadian  staff  feels.  First,  there  are  prob- 
lems with  the  Interdata  70  processor.  It  is  restricted  to  64K 
bytes  of  mernor,',  had  a poorly  designed  operating  system,  and 
(contrary  to  the  Canadian's  expectations)  Interdata  did  not 
upgrade  tliis  machine  later  but  instead  switched  to  a new  design 
Consequently,  the  project  has  obsolete  hardware  and  unsupportiJ 
system  software.  The  operating  system  currently  in  use  repre- 
sents a 707  modification  of  Interdata's  RTOS. 
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Oiir  undf  rstand  i ot  ttif  >;fiu'ral  feeling  amon^  the  (\'in.idian 
stall  is  that  while  minicomputers  are  quite  suitable  for  lar^e 
distributed  processing  systems,  tlie  following  four  constraints 
siiould  be  an  integral  part  of  system  design: 

1.  Software  must  be  upward  compatible  within  ttie  family  of 
machines  to  facilitate  using  new  hardware  as  it  becomes 
available . 

2.  Off-the-shelf  operating  systems  should  be  used. 

3.  Application  programming  should  be  done  in  a higher  order 
language  both  for  reasons  of  portability  and  maintainability 

4.  Allowance  should  be  made  for  memory  expansion. 

The  Canadians  have,  in  fact,  taken  their  own  advice  in  implement 
ing  a new  system,  called  the  Oceanic  system,  which  uses  two 
PDP-ll/40's  to  support  24  terminals.  Here,  80-90%  of  the  code 
is  in  F0RTR(\N  with  the  remainder  in  assembly  language,  and  the 
operating  system  is  DEC's  RSX-llM. 


3-19 


A third  (luminiiii  i i;i  t 1 (’IIS  conlri’l)  svslcm  usi-s  .1  l’l)l’-ll/  t‘>,  with 


pro>’,r.inn i nv.  ap,.iin  in  F<)RTKAN. 

Since  the  JETS  svsten  is  not  yet  operational,  no  conclusions 
can  he  drawni  as  to  its  perfornance  or  prac t ica 1 i t v . The  main 
benefit  to  be  Kleaned  from  a studv  of  this  system  is  that  of 
learning  some  major  pitfalls  of  multi-minicomputer  system 
des  i gn . 


The  attitude  of  the  Canadian  Air  Transportation  Ministry  toward 
distributed  processing  was  summarized  in  the  joint  MITRE/FAA 
report  : 

Although  problems  were  encountered  in  the  development  of 
the  JETS  system,  a commitment  to  minicomputers  with  more 
stringent  software  standards  continues  in  future  develop- 
ment systems.  The  low  cost  with  higher  reliability 
forms  the  basis  for  this  approach. 

3.1.b  MITRi  MTI  Multicomputer  Network,  Bedford 

Ihe  purpose  of  this  network  is  to  do  the  data  processing  for 

i.EODS.S,  which  is  itself  a network  of  telescopes  to  search  the 

night  sky  for  distant  man-made  earth  satellites.  Detection 

is  based  on  the  relative  movement  of  satellites  compared  to 

the  fixed  star  background.  A sensor  is  used  to  scan  the  star 

field,  in  raster  form,  and  then  after  10  seconds,  the  field  is 

scanned  again  and  the  images  compared  for  any  telltale 
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ii'.d  icat  ions  of  niovonont  . The  opi'ratlon  is  dfso  r ibed  In  deLail 


in  MlikK  Report  M7b-d01. 


Ti:e  .int'unt  of  raw  computing  power  required  to  implement  the 

seanhing  algorithm  is  enormous:  approximately  9 million 

operations  per  second.  Implementation  by  a single  machine 

would  have  required  either  a CDC  Cyber  176  (rated  at  13  MIPS) 

or  a Uh'IVAC  1100/40  (rated  at  II  MIPS).  An  alternative  strategy 

was  to  subdivide  the  task,  and  implement  it  on  a group  of  mini- 

com.puters.  The  nature  of  the  task  lends  itself  to  parallel 

processing,  and  this  is  how  the  final  system  was  configured, 

using  10  minicomputers.  A block  diagram  of  the  network  is 

shown  in  Figure  'i-6,  and  the  data  flow  in  Figure  3-7.  The 

minicom.puters  used  are  Data  General  NOVAs,  having  an  instruction 

rate  (fixed  add)  of  1.2MHZ,  with  a bus  transfer  rate  of  I.IM 

bits/second.  Dr.  Hiram  Connell,  designer  of  the  system,  sum- 

nari,:es  the  advantage  of  this  hardware  configuration: 

;he  net  results  of  the  division  of  tasks  and  data 
are  that  the  storage  associated  with  each  computer 
is  reduced  to  minicomputer  dimensions,  and  process- 
ing speed  requirements  are  reduced  to  manageable  rates. 
Fight  of  the  computers  comprising  this  MTI  system 
contain  16K  words  of  16-bit  storage,  and  two  have  24K 
words  of  storage.  The  computer  instruction  rates  are 
a nominal  1.2.MHz.  This  reduction  is  achieved  by  not 
requiring  anv  one  computer  to  contain  an  entire  data 
set  and  by  not  requiring  any  computer  to  perform  a 
complex  processing  task.  Furthermore,  each  of  the 
parallel  processing  branches  contains  an  identical 
computer  with  identical  software.  Peripheral  equip- 
ment for  one  master  computer  is  all  that  is  necessary 
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to  dfvolop  software  and  operate  the  network.  The 
entire  .software  packaj^e  for  the  spec:!!  if  MTI  appliiation, 
leserlbed  here,  Is  .scmewhat  larger  than  would  be  rc- 
(juired  to  Implement  the  same  process  In  one  large 
computer;  Irowever,  the  modularity  of  the  programs 
result  in  a lower  cost  and  more  error-free  software 
development.  Since  each  small  program  has  well  defined 
interfaces,  modularity  is  nearly  complete.  The  end 
result  is  that  a form  of  enforced  structured  progr.amming 
evolves  in  the  development  of  the  applications  soft- 
ware. Kach  computer  contains  isolated  program  segments. 
Owing  to  the  functional  independence  of  each  program 
segment,  software  development  may  proceed  independently. 
For  the  snapshot  MTI  process,  program  development  was 
rapid.  . . . 

The  total  hardware  cost  for  this  system  is  $200,000,  or  about 

107  of  the  equivalent  large  mainframe. 


Software  and  operating  system,  problems  were  also  minimized  by 

use  of  what  Dr.  Connell  refers  to  as  an  'implied  executive'. 

As  Dr.  Connell  explains  it: 

If  the  requirements  for  proper  inputs  are  strict 
within  each  computer  program  in  each  network  element, 
then  a distributed  form  of  control  exists;  namely, 
each  program  will  operate  properly--as  soon  as  it 
receives  its  data.  By  preparing  a grand  plan  for 
data  flow  and  approximately  balancing  the  amount 
of  processing  required  of  each  computer  element 
before  configuring  the  computer  system,  the  execu- 
tive is  implied. 

But  clearly  this  type  of  architecture  is  onlv  possible  tor  job 
where  the  input  and  data  processing  loads  are  not  only  known, 
but  are  constant;  it  could  not  be  used  if  the  input  or  pro- 
cessing were  governed  by  any  type  of  stochastic  proce.ss. 
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So  despltf  its  eleganoe  and  efficiency,  this  architecture  Is 


not  suitable  for  the  FSS  application,  which  does  deal  with 
widely  varyini^  loh  loads,  and  inputs  governed  by  stochastic 
processes . 


3.1.7  Kansas  State  University 
Dr.  Paul  Fisher,  Chairir.an  of  the  Kansas 
puter  Sciences  Department,  is  in  charge 
processing  developmental  effort  for  the 


State  University  Com- 
of  a distributed 
Department  of  the 


Army . 


The  Army  laid  down  general  guidelines  for  the  project,  among 
them  two  of  great  importance:  (1)  Network  must  be  transparent 
to  the  type  of  processor  used,  and  (2)  operating  systems  of  the 
various  machines  used  could  not  be  modified. 


Since  the  system  is  not  complete,  only  general  information 
about  it  is  presently  available.  Following  is  an  exerpt  from 
the  MITRE/FAA  distributed  processing  report  dealing  with  this 
installation. 

The  limitations  placed  on  the  network  led  to  the 
selection  of  a microprocessor  interface  to  a high 
speed,  byte  parallel,  10  megabite  transfer  rate  bus. 

The  network  supervisor  will  reside  in  the  micro- 
processors and  will  treat  the  minicomputers  as 
resources.  The  network  will  be  complete  about  mid- 
summer and  will  consist  of  three  nodes  connected 
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through  ,T  commnnic.it  ion  intorfacf--KSr  570/1 'j.H, 

DKC  rDP-11/70  and  a clusli'r  oi  minis  .it  tlu'  KSl’ 

Computer  Science  Department.  The  cluster  will 
be  two  Interdata  8/32's,  one  Interdata  7/16  and 
a Data  General  N’OVA.  The  microprocessors  will  be 
Interdata  5/16s. 

The  OS  overhead  in  the  cluster  was  approxim.itely 
407.  The  system  programs  were  written  in  assembly 
language  although  the  application  programs  were  in 
standard  COBOl. . 

Based  on  the  definition  of  [FSS]  system  requirements, 
the  following  recommendations  were  made: 

[Since]  Most  minicomputer  problems  are  disk  oriented, 

[the  following  should  be  used]; 

• Core  Memory 
Parity  Checking 
32  Bit  Word  Size 

...  program  [should]  be  task  oriented  and  hard- 
ware assignment...  based  on  system  priorities  and 
hardware  availability.  [The]  big  risk  is  not  buy- 
ing enough  hardware  to  perform  function.  (Recommend 
1002  plus.)  This  is  especially  true  if  [it  is] 
difficult  to  estimate  ...  future  requirements. 

The  32  bit  word  size  recommendation  comes  about  because  of 

the  floating  point  arithmetic  required  for  route  processing; 

however,  this  forms  a small  enough  portion  of  the  overall  job 

that  it  should  not  be  the  driving  force;  and  in  fact  the 

existing  MITRE  experimental  PSBT  System  does  not  have  32 

bit  words  and  still  adequately  handles  all  arithmetic  functions. 

The  other  recommendations  will  be  discussed  below. 
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i.l.H  DCS,  University  of  California,  frvlne 


The  DCS  (Distributed  Computing  System)  at  the  University  of 
t.illfornla,  Irvine  Is  under  the  aegis  of  Prof.  David  Karber, 
and  Is  one  of  the  better  known  distributed  processing  systems 
in  operation  today,  and  probably  the  best  example  of  ring 
architecture . 

The  DCS  installation  was  documented  in  Datamation , February 
197S,  and  consists  of  three  I.ockheed  SUE  machines  and  two 
Varian  6201  machines,  none  of  which,  according  to  Professor 
Farber,  is  exceptionally  reliable,  though  all  were  up  at  the 
time  of  the  MITRE/FAA  visit.  The  machines  are  interconnected 
via  a ring,  the  hardware  for  which  was  designed  and  built 
using  TTL/SSI  chips.  There  is  no  buffering  of  data  by  the 
Individual  ring  interface;  only  a one  bit  delay  used  for 
synchronization.  Traffic  moves  in  only  one  direction  around 
the  ring,  and  there  is  a round-robin  polling  of  the  machines 
on  the  ring  so  that  no  one  machine  can  saturate  the  ring  with 
continuous  transmission.  Messages  contain  a source  and  desti- 
nation code,  a length  indicator,  and  several  bits  which  are 
set  or  not  depending  on  whether  the  message  was  received  and 
accepted.  Obviously  each  ring  interface  represents  a potential 
single  point  of  failure,  though  to  date  (after  2-1/2  years) 
none  has  failed. 
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; !u‘  sDttw.iro  tor  iho  system,  written  largely  in  a iilgiier  level 
lar.guage  developed  for  the  purpose,  Is  designed  to  be  fall- 
sol  t rather  th.ui  lail-sali",  thoiigli  the  system  iloes  have  t a i r 1 y 

sophisticated  methods  for  detecting  errors  and  dealing  with 
them.,  including  saving  the  process  environment,  starting  a test 
process,  initiating  another  copy  of  the  processor  which  failed, 
or  merely  suspending  all  .ictivity  until  some  explicit  in- 
structions are  received  from  an  operator.  There  '' s .1  auto- 
matic restart  ot  programs,  and  limited  reconfiguration  capability. 
The  system  is  designed  for  experimentation,  teaching,  and 
research,  so  only  supports  five  term.inals,  though  more  could 
be  added  If  desired. 


A block  diagram  of  the  system  is  shown  in  Figure  3-8.  There 
is  no  m.aster  operating  system  per  se ; the  system  is  based  on 
processes , not  processors,  with  the  goal  of  distributing  not 
just  hardware,  but  control  and  function.  According  to  Prof. 
Farber ; 

bach  processor  on  the  ring  has  a resident  software 
system  called  the  nucleus.  The  nucleus  provides 
facilities  for  the  scheduling  of  processes  and  for 
transmitting  and  receiving  messages.  Other  system 
functions,  such  as  resource  allocation,  device  1/0, 
and  file  system  services  are  provided  bv  processes 
executing  in  the  DCS.  Because  the  nucleus  is  the 
only  software  absolutely  bound  to  a particular  pro- 
cessor, all  other  system  services  may  be  executed  by 
any  machine  in  the  ring  and  can  be  accessed  from  anv 
user  processes  through  the  message  system.  A process 
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rcMjliPst  i ng  stTvlrp  add res.sc's  roqiwsls  by  name,  it 
does  net  nee<l  to  know  where  in  the  system  the  needed 
service  process  resides.  A request  for  a service, 
issued  at  job  initiation  or  whenever  a new  res<'urce 
is  needed,  are  recognized  by  all  the  processors  in 
tlie  system.  Those  processors  with  available  resources 
in  effect  "bid"  to  supply  the  service.* 

H.irdware  and  software  problems  are  detected  by  means  of  the 

Interprocessor  protocol  (status  bits  set),  and  time-outs. 

Most  overhead  connected  with  this  system  is  not  attributable 

to  the  distributed  processing  configuration,  but  to  the  error 

detection  and  processor  (not  process)  restart  software  required 

for  fail-soft  operation. 

According  to  Professor  Farber,  there  are  systems  being  con- 
structed for  real-time  applications,  but  apparently  none  is 
yet  operational. 

There  would  most  likely  be  some  problems  in  attempting  to  apply 
this  architecture  as  it  stands  to  the  FSS  system,  because  of 
the  potential  single  point  of  failure  represented  by  the  ring. 
But  the  ring  could  easily  be  duplicated  and  if  sufficient 
safeguards  are  designed  into  tiie  system  to  prevent  one  runaway 
machine  from  contaminating  the  others'  data  bases  or  memories, 
this  might  well  be  a practical  approach  to  FSS  design. 

* Prof.  David  Farber,  'A  King  Network',  Datamation,  op.clt.,  p.  46. 
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A detailed  report  on  this  system  Is  available,  Including 
reconmendat Ions  for  future  ring-based  architectures.* 

3 .1.9  Carter  Associates,  Cupertino,  California 
The  MITRK/F/\r\  team  visited  one  site  having  a TANUF.M  Computer 
Svslem.  .Since  the  TANDEM  system  architecture  and  hardware 
appears  to  be  suited  to  the  FSS  application  and  meets 
most  of  the  stringent  fail-safe  requirements  as  well,  the 
team  wanted  to  learn  about  a customer's  actual  experience  with 
the  system. 

Presently  Carter  Associates,  which  is  a data  processing  house, 
uses  three  IB.M  360 ' s (2  65 's  and  1 40)  in  batch  mode  to  provide 
services  to  their  customers.  These  services  include  payroll, 
inventory  control,  order  processing,  etc.  They  decided  that 
an  Interactive  system  might  be  more  flexible  and.  If  Imple- 
mented with  minicomputers,  less  expensive  and  potentially 
more  reliable.  They  considered  DEC  and  Data  General  machines, 
and  were  on  the  verge  of  buying  an  Eclipse  for  this  appli- 
cation when  TANDEM  announced  its  system,  which  they  decided  to 
purchase  Instead.  Their  conf igui at  Ion  consists  of  two  pro- 
cessors, with  about  30K  of  semiconductor  memory  per  processor, 

* The  ulstrlbutea  Computing  Operating  System.  Lawrence  A.  Rowe, 
Technical  Report  //66,  June  1975,  published  by  the  Department  of 
Information  and  Computer  Science,  University  of  California,  Irvine, 
California,  92664. 
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oiu-  disk,  ont'  virive,  ami  sovcial  I f rr.l  n.i  1 s . Wlii'n  tVielr 

Inti-ract.  1 Vf  liatn  habt*  deve iopinont  soitwaro  is  complete",  they 
plan  to  expand  their  present  coni’ i ^urat  Ion  with  additional 
processors  and  peripherals.  Up  to  now  they  have  written  their 
software  in  TAI,  (TANDF.M's  own  hi^h  level  lanRuaj'e,  similar  to 
AI.CIDL)  , but  intend  to  convert  to  COBOL  when  released  later 
this  year. 

Carter  Associates  Is  satisfied  with  their  system,  though  its 
operation  has  not  quite  been  non-stop.  There  have  been  approxi- 
mately two  hours  of  down  time  since  the  system  was  Installed 
in  August  of  1976.  This  down  time  was  attributed  to  software 
bugs  (since  fixed).  Two  hours  of  down  time  In  6 months 
corresponds  to  an  availability  of  .9995. 

3.1.10  MITRE  TICCIT  System,  Washington 

TICCIT  (Time-shared  Interactive  Computer  Controlled  Information 
Television)  Is  a minicomputer  based  distributed  processing 
system  dedicated  to  student  instruction.  It  is  a relatively 
small  system  computer-wise,  (2  computers,  1 display  generator), 
but  is  similar  to  the  FSS  application  in  that  it  handles  loads 
whose  distribution  is  Poisson,  and  the  processing  required  for 
each  transaction  can  vary  over  a wide  range.  In  addition,  the 
system  logs  all  entries,  does  frequent  checkpointing,  and  has 
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some  automatic  restart  capability  (though  no  automatic  recon- 


figuration). It  is  capable  of  driving  up  to  128  terminals, 
each  displaying  up  to  lOOK  bits  of  information  in  7 colors. 
Update  time  for  completing  changing  a display  is  about  100 
msec  . 


The  original  purpose  of  the  TICCIT  system  was  to  demonstrate 
the  feasibility  of  low-cost  computer-aided  instruction  by 
employing  minicomputer  technology.  The  system  is  described 
in  detail  in  two  MITRE  publications,  M76-44,  An  Overview  of 
the  TICCIT  Program,  and  .M76-52,  TICCIT  System  Specification. 

A generalized  block  diagram  of  It  Is  shown  in  Figure  3-9,  and 
a block  diagram  of  the  computer  system  as  installed  at  two 
operational  sites  in  Figure  3-10. 

All  TICCIT  systems  have  four  basic  components:  a main  computer 
system  referred  to  as  the  "main  processor"  and  its  associated 
data  base;  a terminal  computer  system  called  the  "term.inal 
processor"  together  with  its  data  base;  a display  generator  and 
refresh  system;  and  student  terminals  composed  of  color  TV 
receivers  and  keyboards. 

The  main  processor,  utilizing  the  TICCIT  courseware  data  base, 
creates  and  assembles  frames  to  be  displayed  on  student 
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FIGUft(  3 10 

TICCiT  COMPUTER  SvSTtV 


terminals  as  a function  of  course  material  and  student  response. 
Tasks  of  the  nuiln  processor  are  diverse  and  relatively  slow- 
paced, and  Include  record  keeping  and  student  answer  processing. 
The  terminal  processor  performs  all  fast-reaction,  highly- 
stereotyped  functions;  It  Interacts  with  the  TICCIT  student 
terminals,  and  does  frame  and  audio  outputting  as  well  as  key- 
board Input  multiplexing. 

One  of  the  more  unique  features  of  the  system  Is  Its  display 
terminals.  A terminal  displays  alphanumerlcs  and  graphics  In 
seven  colors,  under  computer  control,  as  well  as  full-color 
videotapes.  Up  to  1?  lines  of  43  characters  each  may  be  dis- 
played . 

Graphic  displays  are  constructed  on  a bit  by  bit  basis  on  a 
grid  of  204  elements  in  the  vertical  direction  by  430  elements 
in  the  horizontal  direction.  The  color  of  each  half-character 
(l.e.,  6 X 10  block  of  bits)  may  be  individually  specified. 

Full  color  videotapes  add  variety  to  the  computer/student 
interaction  and  give  the  course  author  a powerful  tool  to 
dramatize  difficult  concepts. 
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To  tiirther  auKuient  tlu>  vinual  display,  the  terminal  loud- 
■ipf.iker  (or  lioadphones ) brings  prerecorded  messages  under 
computer  control. 

Although  the  TICCIT  system  itself  is  not  powerful  enough  to 
handle  the  FSS  job,  it  does  clearly  demonstrate  that  a large 
number  of  interactive  terminals  can  be  driven  by  a distributed 
processing  system  which  must  process  inputs  from  the  terminals, 
access  a large  data  base,  and  display  responses  to  them  quickly 
(average  TICCIT  response  time,  under  full  load,  is  better  than 
1 second).  Furthermore,  these  terminals  may  be  separated  from 
the  main  processing  unit  by  great  distances. 

3.1.11  ARP/\NET 

The  widely-known  ARPANET  is  basically  a packet  switched  com- 
munication system  interconnecting  a large  number  of  existing 
machines.  This  type  of  'distributed  processing'  is  the  geo- 
graphically distributed  kind,  with  which  this  report  is  not 
concerned.  However,  a multiminicomputer  system  is  being 
developed  to  serve  as  a switching  node  for  the  ARPANET.* 


* See  'A  New  Mlnicomputer/Mult Iprocessor  for  the  ARPA  Network', 
1973  National  Computer  Conference.  AFIPS  Conference  Proceedings, 
1973,  pp.  529-537. 
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. I J PARC  Syslftr. 

Till'  PART  (1)1  felt  Across  K.ular  Channel)  System,  designed  bv 
Ravtheon  as  .1  partial  backup  for  the  9020  Computers  in  the 
20  ARTCC's,  is  a distributed  processing  system  in  the  form  of 
a st.ir,  but  icith  a hvbrid  distributic'n  of  functions.  1 1 is 
implemented  partially  as  a load  sharing  system  (for  display 
processing),  and  partially  as  a function  sharing  system  (for 
central  control  functions).  The  purpose  of  the  system  is  to 
pcrm.it  display  of  radar  data  on  PVD's  In  the  event  of  a 
failure  in  the  9O20's  at  any  Center.  A block  diagram  of  the 
system  is  shown  in  Figure  3-11. 

The  system  is  capable  of  expansion  to  accommodate  both  the  addition 
of  radars  and  addition  of  display  processors (DP ' s ) . Additional 
functions  can  be  added  to  the  existing  Control  Processor  or 
hv  expanding  the  number  of  Control  Processors.  The  system  is 
not  fail-safe,  hut  it  does  have  some  redundant  elements  and  is 
capable  of  manual  reconfiguration. 

The  minicomputers  used  for  processing  are  all  Raytheon  RDS-500 
machines,  which  are  somewhat  smaller  and  less  powerful  than 
the  FSS  system  will  probably  require  (maximum  memory  capacity: 

128K  bytes).  The  operating  system  and  the  application  software 
are  written  in  assembly  language,  probably  due  in  part  to  the 
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FIGURE  3 11 

DARC  SYSTEM  ARCHITECTURE 


llnilt.cd  memory  capacity  of  the  machine.  The  first  system  is 
scheduled  to  be  delivered  to  NAFEC  in  March  1978. 

Overall,  this  system  demonstrates  the  feasibility  of  employing 
large  numbers  of  minicomputers  to  perform  a group  of  related 
tasks,  but  like  the  MITRE  MTI  system,  is  an  ideal  application 
for  minis  because  of  the  Inherent  parallel  nature  of  much  of 
the  processing,  and  the  fact  that  the  system  load  is  not 
governed  by  the  same  type  of  stochastic  process  as  expected  in 
the  FSS  system.  Hence,  the  DARC  architecture  cannot  be  considered 
directly  applicable  to  the  FSS  system  requirements. 

With  respect  to  the  feasibility  of  large-scale  minicomputer 
based  distributed  processing  systems,  Raytheon  noted  in  a 
briefing  to  the  FAA  that  such  systems  have  been  built  for  ATC 
use  in  Switzerland,  Mexico,  South  Africa,  Japan,  Netherlands, 
Canada  and  the  United  States. 

3. 1.13  DABS  System 

DABS  (Discrete  Address  Beacon  System)  seeks  to  update  the 
present  transponder  based  system  in  NAS.  The  computer  portion 
of  the  system  has  as  its  task  the  acquisition,  processing  and 
management  of  radar  data.  Total  processing  power  required  is 
about  3 MIPS,  which  is  handled  by  12-15  microprocessor  "units." 
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Each  unit  consists  of  two  microprocessors  strapped  together, 
running  on  a common  clock,  and  receiving  the  same  inputs.  At 
critical  junctures,  e.g.,  before  a memory  write,  the  outputs 
of  the  two  processors  are  compared  by  a special  hardware  device, 
and  if  different,  the  "unit"  is  considered  to  have  failed  and 
a flag  is  set.  A new  unit  is  then  switched  in.  The  system 
functions  with  256K  of  global  memory,  and  8K  per  unit  for  pro- 
gram storage  and  scratch  pad  use.  Theoretically,  there  are 
no  single  points  of  failure  which  can  result  in  global  data 
contamination.  The  design  goal  is  20,000  hours  MTBF  for  the 
overall  system. 

To  date,  only  a few  of  the  processing  units  have  been  built, 
and  it  is  not  yet  known  how  well  the  12  Interconnected  will 
function,  or  if  any  problems  will  develop. 

This  system  is  similar  in  type  to  the  MITRE  MTI  system  dis- 
cussed in  Section  3.1.6,  and  the  same  remarks  in  reference  to 
the  FSS  application  apply  to  it,  though  of  course  with  respect 
to  reliability  DABS  is  inherently  superior  and  illustrates 
another  approach  to  fail-safe  design. 
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3.1.14  ARTS  III-A 


ARTS  (Automatic  Radar  Terminal  System)  III-A  is  an  enhanced 
version  of  ARTS  III,  designed  to  provide  redundancy,  degraded 
modes  of  operation  and  radar  tracking. 

The  system  employs  two  Sensor  Reception  and  Processing  units 
(SRAP)  and  two  Input/Output  Processors  (lOPs).  Each  SRAP  has 
4K  bytes  of  memory,  and  the  lOPSs  share  a common  memory  bank  of 
96K  bytes.  I'NIVAC  is  developing  the  system,  and  the  first  pro- 
totvpe  is  scheduled  to  be  operational  at  Tampa  shortly. 

This  system  is  not  particularly  closely  related  to  the  FSS 
application  both  because  of  the  load  (see  Sections  3.1.6, 
3.1.13),  and  because  the  hardware  is  not  standard  off-the- 
shelf  commercial  minicomputers. 

AW/VNS 

AWAiNS  (Automated  Weather  and  NOTA.M  System)  is  basically  a mini- 
computer based  distributed  processing  system  whose  function  is 
to  process  and  display  weather  data  and  flight  plans,  quite 
similar  to  the  way  envisioned  for  the  FSS.  It  maintains  a 
national  aviation  weather  data  base,  and  permits  various  methods 
of  retrieval  and  display  of  the  data.  Included  are  both 
graphical  and  live  weather  data. 


3-42 


The  hardware  Is  comprised  of  three  GTE  TEMPO  II  processors, 
each  containing  128K  bytes  of  memory  (the  maximum  for  this 
machine),  four  cartridge  disks,  two  tape  drives,  one  line 
printer,  two  character  printers,  18  keyboards  and  14"  raster 
scan  displays,  and  three  teletypes.  The  system  normally  runs 
with  two  processors  on  line,  and  if  one  fails,  the  third  is 
manually  switched  Into  the  system.  Several  vendors  supplied 
the  hardware,  and  E-Systems  integrated  it. 

The  operating  system  and  applications  programs  were  written 
in  assembly  language.  The  Atlanta  system  was  delivered  in 
June  1975  and  is  operational.  A second  system  was  delivered  to 
Leesburg  in  February  1977. 

Since  AWANS  was  intended  as  a prototype  FSS,  it  is  similar  in 
design  and  function,  but  without  all  the  capabilities  of  the 
FSS,  nor  its  fall-safe/fall-soft  requirements. 

3.2  Conclusions  from  Survey  of  Existing  Distributed  Proces- 
sing Systems 

3.2.1  Reasons  for  Selecting  Distributed  Processing  Architecture 
Nearly  all  users  agreed  on  four  reasons  for  preferring  dis- 
tributed processing:  (a)  Cost,  (b)  Reliability,  (c)  Modularity, 
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(il)  l,xi)ann  111  1 I I ty  . I’n  for  t iiiia  tc  1 y , very  lltLie  hard  data  art- 
aval  InMe  on  how  well  disLrlhuted  systems  are  lIvlnK  up  to 
their  promise  of  reliability,  and  for  the  most  part  expansi- 
bilitv  is  theoretical  rather  than  actually  demonstrated.  As 
for  items  (a)  and  (c),  however,  there  is  very  little  doubt  that 
distributed  systems  fulfill  their  promise. 

3.2.2  Availability  of  Hardware 

Hardware  currently  available  off-the-shelf,  including  proces- 
sors, disk  systems,  tape  drives  and  other  peripherals  as  well 
as  interprocessor  busses,  is  adequate  for  the  FSS  application. 
There  is  at  least  one  vendor  who  seems  to  have  all  the  hardware 
needed.  Including  that  required  for  automatic  reconfiguration 
and  fail-safe  operation,  available  in  a package  which  is  com- 
pletely off-the-shelf.  Most  other  vendors  offer  various  pieces 
of  the  required  gear  (such  as  dual  ported  peripherals,  dual 
busses,  special  power  supplies,  etc.),  so  that  is  is  all  avail- 
able in  one  form  or  another,  but  some  development  may  be  re- 
quired to  assemble  and  integrate  it. 

3.2.3  Availability  of  Software 

Nearly  all  vendors  offer  a real-time  multitasking  operating 
system  off-the-shelf,  which  is  capable  of  sustaining  fairly 
sophisticated  developmental  efforts.  There  is  at  least  one  who 
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offers  a real-time  multiprocessing  operating  system  meeting 
most  or  all  of  the  FSS  requirements,  but  most  sites  currently 
existing  either  wrote  all  of  their  own  operating  system  (e.g.. 
Southern  Bell,  DCS,  C.mmp),  or  substantially  modified  existing 
operating  systems  (e.g.,  JETS).  Most,  however,  did  not  recommend 
this  procedure. 

The  software  to  support  automatic  reconfiguration  and  fail-safe 
operation  is  available  off-the-shelf  from  only  one  vendor  from 
among  those  we  investigated,  and  for  other  equipment  would  have 
to  be  developed  in  conjunction  with  the  necessary  hardware. 
Several  sites  did  have  manual  reconfiguration  capability. 

Higher  level  language  availability  is  summarized  in  Section  2.3. 
The  MITRE/FAA  study  team  determined  that  only  one  vendor  liad 
its  COBOL  compiler  tested  by  the  Navy  testing  center  (Data 
General),  so  in  most  respects  compiler  performance  cannot  be 
guaranteed . 

3.2.4  Systems  of  Comparable  Size  and  Scope 

As  the  MITRE/FAA  team  concluded,  no  single  operational  site  or 
system  has  been  found  which  approximates  the  size  and  workload 
anticipated  for  a typical  FSS  Hub.  But  when  all  sites  are  taken 
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c <1 1 Ifc' t I vi' 1 V , iiiiiKi  niajor  funct  If'iiK  refiiilri'd  nppcnr  to  liavo 
imp  iempriter)  or  .ire  being  developed. 

3.2.5  Recoirunendatlons  of  Current  Users 

Those  who  .ire  currently  using  or  developing  distributed  pro- 
cessing systems  made  several  recommendations  which  should 
prove  most  valuable.  First,  with  regard  to  hardware  they 
recommended  that  equipment  be  purchased  which  is  upward  com- 
patible and  more  powerful  than  present  estimates  call  for,  both 
with  respect  to  CPU  and  memory.  Nearly  all  at  first  under- 
estimated the  processing  power  required  for  their  job.  Second, 
with  respect  to  software,  nearly  all  recommended  that  higher 
level  languages  be  used  for  application  programs,  and  most  ad- 
vocated vendor  supplied  operating  systems,  although  such  ob- 
viously do  not  exist  for  some  of  the  more  exotic  architectures, 
such  as  DCS.  Third,  regarding  overall  system  performance,  most 
felt  that  a comprehensive  benchmark  was  essential  to  assure 
that  a machine  lives  up  to  its  specifications.  Fourth,  most 
stressed  procurement  of  premium  grade  hardware  and  peripherals. 
The  savings  realized  by  buying  cheap  hardware  was  used  up  many 
times  over  during  later  problems  with  l.ardware,  software  de- 
velopment, poor  reliability,  schedule  slips,  etc. 
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4.  TWO  SAMin.E  DESIGNS  FOR  THE  FXICHT  SERVICE  STATION  HUB 

Nt'xi  , n typical  function  sharing  and  a typical  load  sharing  con- 
figuration for  the  FSS  system  will  be  described  and  analyzed, 
rhe  purpose  of  this  exercise  is  to  show  the  feasibility  of  con- 
structing an  FSS  Hub  capable  of  meeting  all  requirements  of  the 
current  version  of  the  Flight  Service  Station  specification 
using  off-the-shelf  hardware,  and  to  analyze  the  expected  per- 
formance of  such  a system  under  peak  anticipated  load.  An 
evaluation  of  the  results  of  this  section  may  be  found  in 
Section  4.3,  and  a performance  summary  in  Table  4-28. 

There  is  no  implication  that  these  are  the  only  or  the  best 
designs  for  the  Flight  Service  Station,  nor  that  they  are  the 
designs  recommended  by  The  MITRE  Corporation  or  the  Federal 
Aviation  Administration. 

This  Is  not  a complete  analysis  and  it  is  based  on  a number  of 
assumptions.  It  is  intended  to  substantiate  reasonable  con- 
figurations as  examples  of  possible  approaches  to  the  FSS  problem. 

4.1  Function  Sharing  Configuration 

In  this  type  of  configuration,  the  overall  job  is  split  up  into 
functions  which  are  assigned  to  machines,  either  dynamically  or 
permanently.  Here  a permanent  assignment  will  be  assumed.  A 
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lirul  Imlnary  deslKH  will  be  Illustrated,  hast'd  on  sysletii  tlirouKb 
put  considerations  alone.  Then  a more  powerful  system  will  be 
shown,  and  both  subjected  to  a queuing  analysis  to  ascertain 
their  expected  level  of  performance. 

4.1.1  Assumptions 

To  analyze  the  performance  of  a function  sharing  distributed 
processing  system,  the  following  assumptions  will  be  made: 

1.  FSS  functions  are  broken  up  into  five  major  categories 

a.  Data  Base  Maintenance  and  Update 

b.  Flight  Plan  Processing 

c.  Weather  Retrieval 

d.  Route  Processing 

e.  I/O  Processing,  Formatting,  and  Display; 

Misce 1 laneous 

2.  Data  base  maintenance  is  done  in  the  special  manner 
explained  below.  Section  4.1.3. 

3.  TAN’DEM  computers  will  be  used  for  sizing  and  costing 
purposes . 

4.  Speed  of  TA.N'DEM  machines  assumed  to  be  that  of  NAS 
instruction  mix. 

5.  Overhead  is  assumed  to  be  60%  of  operational  software. 
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6.  FSS  Hub  0*11  requirements  are  as  in  Appendix  B,  with 
modifications  uh  noted. 

7.  No  processing  will  begin  until  all  entries  required 
have  been  made. 

Tlie  effect  of  relaxing  assumption  (7)  will  be  discussed  in 
Section  4.3. 

The  data  flow  for  the  three  major  FSS  functions  (Route  Briefing, 
Local  Briefing,  and  Flight  Plan  Filing)  are  shown  in  Figures 
4-1  through  4-3. 

4.1.2  Estimate  of  Number  of  Machine  Instructions/Second 
Required  by  Pilot  Briefing  Functions 

Based  on  the  data  in  Appendix  B,  and  the  function  split  de- 
scribed in  Section  4.1.1,  the  number  of  instructions/second 
required  to  perform  the  work  in  each  of  the  five  functional 
areas  can  be  determined  for  the  1995  Peak  Hour  Load. 

4. 1.2.1  Raw  Computing  Power  Required 

The  following  sections  estimate  the  number  of  machine  Instruc- 
tions/second required  by  pilot  briefing  functions. 

4. 1.2. 1.1  Data  Base  Maintenance  and  Update 

1000  msgs/240  sec*  x lOK  Instr/msg  “ 42K  instr/sec 

* Worst  case  condition  for  data  base  update:  1000  = number  of  SA 
reporting  stations;  240  seconds  • time  of  transmission. 
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FIGURE  4-1 

DATA  FLOW:  ROUTE  ORIENTED  BRIEFING 
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FIGURE  4 2 

DATA  FLOW:  LOCAL  WEATHER  BRIEFING 
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FIGURE  4-3 

BASIC  DATA  FLOW  FOR  FLIGHT  PLAN  FILING 
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-..1.2.1. 


Kl^liL  I'laii  Processing  and  Aircraft  Contact  .Messaces 


lOnp  instr/IPK  flipht  plan  x 299  I FR  f.p./lir 

X 1 hr/ icon  sec  = 8300  instr/sec 

5nK  instr/VFR  flight  plan  x 116  VFR  f.p./hr 

X 1 hr/3600  sec  = 1600  instr/sec 

20K  Instr/AC  Message  x 189  AC  Messages/hr 

X 1 hr/3600  sec  = 1050  instr/sec 

IIK  instr/sec 


4. 1.2. 1.3  Weather  Retrieval 

Items  (b)-(m)  from  Table  B-1  = 680K  instr/ 

briefing  x 606  briefings/hr  x 1 hr/3600  sec  = 116K  instr/sec 

All  items  from  Table  B-2  = 92K  instr /brief ing 

X 307  brieflngs/hr  x 1 hr/3600  sec  = 7850  instr/sec 

124K  instr/sec 


4. 1.2. 1.4  Route  Processing 

430K  instr/route  brief  x 606  brief/hr  x 1 hr/ 

3600  sec  = 72K  instr/sec 

4. 1.2. 1.5  I/O  Processing.  Formatting  and  Display;  Miscellaneous 
Formatting  and  Display:* 

Route  Oriented  Weather  Briefings  (Specialist): 

* Assumes  75%  of  briefings  by  Pilot  using  Direct  Access  Devices 
(Interactive  Telephone  and  Terminal),  and  25%  by  all  other  means. 
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152  brief/hr  x 5000  char/brief  x 10  Instr/char 

X 1 hr/3600  sec  • 2111  Instr/sec 

Route*  Oriented  Weather  Briefing  (Pilot  at  DUAT) : 

^54  brief/hr  x 7540  char/brief  x 10  instr/char 

X 1 hr/3600  sec  = 9508  instr/sec 

Local  Weather  Briefing  (average  for  Specialist 
and  Pilot):  307  brief/hr  x 1500  char/brief  x 

10  instr/char  x 1 hr/3600  sec  = 1279  instr/sec 

I/O  Processing: 

Basic  functions  (Briefings,  Flight  Plans,  Aircraft 
Contacts):  (415  + 606  + 307  + 189)  requests/hr  x 

lOK  instr/request  x 1 hr/3600  sec  = 4214  instr/sec 

Miscellaneous  (Approx.  2 per  each  category  under  'Basic  Functions') 
3000  requests/hr  x lOK  instr/request  x 1 hr/ 

3600  sec  = 8333  instr/sec 

Logging: 

4500  messages/hr  x lOK  instr /message  x 1 hr/ 

3600  sec  = 12. 5K  instr/sec 


38K  instr/sec 
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4 . 1.2.2  Compiit  1 ng  Power  Required  Incliidlnfi  Overhead  and  CPU 
I t 1 1 i ;^at  Ion 

Next,  the  above  estimates  will  be  modified  to  allow  for  system 
overhead  and  (.TU  utilization.* 

4.  1.2. 2.1  Data  Base  Maintenance  and  Update 

42K  inst r x ( 1 ) ( 1 . 6)  = IlOK  instr/sec 

sec.  0.6 

CPU  Utilization  > 

Executive  Overhead  

4. 1.2. 2. 2 P'liRht  Plan  Processing 

IIK  instr/sec  x (1  ) (1 . 6)  = 29K  instr/sec 

0.6 

4. 1.2. 2. 3 Weather  Retrieval 

124K  instr/sec  x ( 1 ) (1 . 6)  = 331K  instr/sec 

0.6 

4. 1.2. 2. 4 Route  Processing 

72K  instr/sec  x (1  ) (1 . 6)  = 192K  instr/sec 

0.6 


* No  allowance  is  made  here  for  expansion  capacity,  as  is  done 
in  .Section  4.2,  because  it  is  assumed  that  any  functional 
expansion  would  be  done  by  addition  of  more  processors,  and 
not  by  increasing  the  functions  assigned  to  any  one  machine. 
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I/O  r rocoss  1 ii>; , Formatting  and  Dlsplny;  Mlscc-l  laiu'n ijh : 


38K  instr/sec  x (1  ) (1.6)  = lOlK  Instr/sec 

0.6 

4.1.  ) Preliminary  Configuration  and  Recoirimended  Configuration 
The  machines  used  for  this  exercise  are  TANDEM-16  processors, 
whose  speed  is  estimated  as  420K  IPS.  With  this  Information 
and  that  calculated  in  Section  4.1.2,  the  number  of  machines 
required  per  Hub  may  be  estimated. 

Given  the  functional  split,  and  considering  peak  hour  through- 
put, one  machine  would  be  adequate  for  Data  Base  Maintenance, 
one  for  Flight  Plan  Processing,  one  for  Route  Processing,  one 
for  Weather  Retrieval,  and  one  for  Terminal  I/O  processing, 
formatting  and  display. 

Because  the  peripherals  are  only  two  port,  and  one  port  is  re- 
served for  the  redundant  processor,  data  base  maintenance  may  be 
envisioned  as  working  in  the  following  manner  in  order  to  off- 
load the  weather  data  base  maintenance  chores  from  the  weather 
retrieval  processor:  one  machine  receives  incoming  weather  data, 
prepares  it  for  storage  (in  blocks  ready  for  transfer  to  disk), 
transmits  them  over  the  bus  to  however  many  processors  are  engaged 
in  weather  retrieval,  which  then  transfer  them  to  disk  by  DMA 
channe 1 . 
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The  alternative  to  this  arrangement  would  be  to  have  each 
weather  retrieval  processor  (if  more  than  one;  see  below,  p.4-12) 
do  Its  own  data  base  maintenance  and  update.  In  that  case,  at 
least  2 weather  retrieval  machines  would  he  required  (331K  Il’S  : 2 
= IbbK  IPS  + 1 lOK  = 275K  IPS).  In  addition  to  being  a duplication 
of  effort,  this  technique  would  reduce  response  time  for  weather 
retrieval  and  could  have  another  adverse  effect:  the  position  of 
items  In  the  data  bases  of  the  machines  might  not  be  identical, 
whereas  weather  data  bases  identical  in  all  respect  are  clearly 
desirable,  especially  for  portability  of  disk  packs  and  cartridges, 
for  copying  of  the  data  base,  etc.  Most  operating  systems  have 
a provision  for  reserving  tracks  on  disks  which  the  operatiiif, 
svstem's  file  handling  programs  will  not  touch,  and  this  feature 
could  clearly  be  used  to  advantage  in  this  case.  The  master  copy 
of  the  weather  data  base  would  remain  with  the  communications 
handling  processor,  and  could  be  transmitted  to  as  many  weather 
retrieval  machines  as  necessary  - a potentially  important  con- 
sideration for  expandability. 

All  processors  are  assumed  to  have  384K  bytes  of  memory.  This 
would  allow  for  multiple  copi< s of  operational  programs  to  be 
stored  in  memory,  so  as  to  speed  execution  when  multitasking  is 
required. 
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Kach  procossor  Is  assl>;ned  two  moving  head  disks  with  one  spare 
for  redundancy.  Each  machine  will  also  have  one  tape  drive,  but 
because  the  tape  drive  Is  not  used  for  on-line  processing,  It  Is 
not  duplicated.  It  may,  however,  be  duplicated  on  any  machines 
used  for  logging. 

A tentative  configuration  based  on  the  foregoing  considerations 
is  sliown  in  Figure  4-A,  with  the  machine  utilization  indicated. 

Significant  system  improvement  may  be  realized  by  reducing  the 
utilization  in  processors  heavily  loaded  (e.g.,  the  weather 
retrieval  processor)  or  the  processors  handling  tasks  requiring 
large  amounts  of  serial  processing  (e.g.,  the  route  processor). 
Assuming  that  these  two  are  in  fact  duplicated,  a second  configu- 
ration is  obtained,  and  shown  in  Figure  4-5. 

The  expected  performance  of  both  of  these  configurations  is 
analyzed  in  Section  4.1.4,  the  first  referred  to  as  the 
"minimal  configuration",  the  second  as  the  "recommended 
conf iguration". 

4.1.4  Queueing  Considerations  For  A Function  Sharing  FSS  System 
In  the  following  sections  a queueing  analysis  is  performed  in 
order  to  estimate  the  response  time  of  the  system  for  the  major 
functions . 
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flit.DMMISDtO  * OUCTIOH  ShA«^iNG  ♦ S5  MOtt  C‘ lGu«AT»ON  f QK 
iMPHoVf  0 MFSPONSI  T M{  liSiSO,  T ASDl  M COMf»'  T!RS 


■ I . I.-'..  1 Uli'iUll  li  111  I 1 iini-(  1 r I t 1 1 .1 1 

In  thf  FSS  Svsti'ir..  ii'spon.sn  tlru-  is  must  liknlv  tn  !>*■  .1  problem 
in  tiiose  I'nmtions  which  involve  .i  series  ot  t.tsks  that  arc 
basic, illv  seri.il  in  nature,  i.e.  permit  very  little  overlapping, 
require  relatively  large  amounts  of  processing  time,  and  large 
numbers  of  disk  accesses.  All  malor  functions  will  be  considered 
in  this  )).iptr,  but  the  worst  case  is  the  route-oriented  briefing. 

In  i'igurt-  4-b  is  a schematic  diagram  of  data  flow  in  a route- 
oriented  briefing,  with  the  important  queuing  points  identified, 
together  with  the  type  of  queirig  model  assumed  for  each.  Usually 
the  most  general  model  was  chosen  (M/G/1)*,  since  service  times 
will  depend  on  liardware  configuration  and  especially  on  the 
actual  software  used,  about  which,  of  course,  little  information 
is  available.  But  a model  had  to  be  chosen  and  certain  assump- 
tions about  software  made.  The  hardware  was  assumed  to  be  T/\NDEM, 
and  the  software  characteristics  those  of  the  application  programs 
running  on  the  MITRE  PDF  11/70  experimental  PSBT  System.  In  many 
cases  estimates  of  distributions  had  to  be  made,  but  where  possible 
these  represent  worst-case  or  near  worst-case  conditions,  so  that 
tile  performance  estimates  obtained  should  be  conservati ve. 

ic 

The  usual  abbreviated  notation  for  queuing  models  is  employed 
for  this  report.  In  that  notation,  for  example  A/B/C,  A repre- 
sents the  interarrival  time  distribution,  which  is  generally 
assumed  to  be  exponential  and  thus  corresponds  to  a Poisson 
distribution  for  arrival  rate;  B is  the  service  time  distribu- 
tion, usually  either  indicated  as  "C"  for  general,  or  E^  for 
Erlang-k  distribution;  C is  the  number  of  servers  in  the  system. 
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FIGURE  4 6 

QUEUEING  POINTS  IN  A FUNCTION  SHARING 
DISTRIBUTED  PROCESSING  CONFIGURATION 


However,  due  to  relatively  low  processor  utilization,  the  model 
is  not  p.irt  i cul  ar  1 V sensitive  to  those  assumptions. 


4.1. A. 2 t^ueuing  Calculations 

In  tills  section  the  dat.i  in  which  response  time  estimates  will 
be  based  is  gathered  and  the  necessary  calculations  made  for 
each  of  the  areas  indicated  in  Figure  4-6. 


4. 1.4. 2.1  Input  (Terminal  1/0  processing)  - 1995  Demand 
A.  Load/hour 

454  PSBT  briefs  0 7500  Char/brief  x 10 

instr/char  (terminal  output)  = 34.05  M instr/hr 

Input  processing  (3  lOK  instructions 

each  = 4 . 54  M 


152  Specialist  briefs  5000  char/brief 

X 10  instr/char  (terminal  output)  = 7.60  M 

Input  Processing  0 lOK  instructions 

each  = 1.52  M 

303  Local  briefs  0 1500  char/brief  x 

10  instr/char  - 4.55  M 


Input  Processing  0 lOK  instructions 

each  = 3.03  M 


189  Aircraft  Contracts  0 20K  instr  each  = 3.78  M 
415  Flight  Plans  0 lOK  instr  each  = 4.15  M 
4500  Logging  messages  0 lOK  instr  each  = 45.00  M 


3,000  Mlscel.  messages  0 lOK  instr  each  = 30.00  M 


138.2  M instr/hr 
» 38K  instr/sec 
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f'l . '^iHMilnn  p<T  r.'imct  »*r  s - qiieiilnj^  model.  This  particular 

(jtii'ii  1 II,'  modi  1 was  < hoseii  for  the  Input  processor  because  it  Is 
verv  r.eneral  and  m.ikes  minimal  assumptions  about  the  nature  of 
the  svstem  modeled.  All  tasks  are  assumed  to  be  of  equal 
priority. 


for  this  model,  expected  queuing  time  is  given  by  the  Pollaczek- 
Kliintchine  equations*,  specifically, 

ECq)  = ^ + s"  ) = p (s  -1-  ^s/s) 

2 (1-0  ) 2 (1-p) 

E(w)  = total  waiting  time  In  system  = + F,(q) 

where  p = utilization 

s = mean  service  time 

„2  = variance  of  service  time 
■^s 

S.  = service  time  for  task  i 
1 

Based  on  the  above  data,  1995  peak  hour  utilization  for  the 
input  processor  is  given  bv 


tasks 


38K  instr/sec 


. 15 


262K  instr/sec 


equivalent  machine  speed 


A.D.  Allen,  Elements  of  Queuing  Theory  for  the  System  Design. 
IB.M  Systems  Journal,  No.  2,  1975,  p.  185 
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Utilization  can  be  calculated  for  other  cases  of  Interest,  using 
the  data  in  Appendices  A and  B.  The  two  parameters  s and  02  are 
the  mean  and  variance  of  the  service  time,  and  can  be  determined 
bv  calculating  the  first  and  second  moments  of  service  time 
using  the  standard  formulae: 

E(s)  = s = V 

T 


i:(s^  = ^ 


2 2 .-.2 
O ' s - (s) 

s 

where  = relative  frequency  of  task  1 


Breaking  down  the  tasks  pei formed  by  the  input  processor,  and 
assuming  that  terminal  output  is  done  in  pages  of  about  500 
characters  each,  the  above  quantities  may  be  determined  based 
on  the  data  in  Appendices  A and  B,  and  the  results  are  summarized 
in  Table  4-1 . 
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TABLE  4-1 

DATA  FOR  ESTIMATISr.  RESPONSE  TIME  VARIANCE 


Task 

Number/hr. 

’’l 

.. 

„ 2 

1.  PSBT  pages 

S810 

.373 

1 

.019 

! 7.08  X 10^ 

1 

1.35  X 10“^ 

2.  PSHT  input  proc. 

4S4 

.025 

.038 

1 

9.44  X 10^ 

-3 

3.59  X 10'^ 

..  ..  -5 

3.  Specialist  pages 

1520 

.083 

.019 

1 

1. 58  X 10 

-4 

3.00  X 10 

-5 

4.  Specialist  input  proc. 

1 

152 

i 

.008 

.038 

3.16  X 10 

! 

1.20  X 10 

-5 

b.  Local  brief  pages 

921 

.050 

.019 

9.58  X 10 

-4 

1.82  X 10 

-5 

6.  Local  brief  Input 

307 

.017 

.038 

6.39  X 10 

-4 

2.43  X 10 

-5 

7.  Aircraft  contacts  ! 

189 

.010 

.076 

7.86  X 10 

5.98  X 10  ^ 

8.  Flight  Plans 

415 

.023 

.057 

1.29  X 10‘^ 

1 

-3 

7.38  X lO"^ 
-4 

9.  Logging 

4 500 

1 

.246 

.038 

i 

9.36  X 10 

' -2 

3.56  X 10 

^“4 

10.  Misc.  messages 

3000 

. 164 

.038  1 

6.24  X 10 

2.37  X 10 

)_2  _A 

= s'"-  (s)  ■=  9. HI  X 10  - (2.92  x 10  >'  = 1.29  x 10 


Tt'.is  i strictly  spcakinR  accurate  only  for  199S  peak  hour  load. 
However,  the  relative  proportions  of  the  different  types  of 
tasks  remains  nearly  constant  for  different  years  and  loads  (see 
■Appendix  A),  so  these  values  for  the  parameters  will  be  assumed 
valic'  for  the  four  system  load  conditions  in  the  cases  con- 
sidered in  this  report. 


Hence,  for  each  of  the  four  cases  of  interest,  p may  be  calculated 
and  using  the  above  parameter  values,  E(q)  determined.  The  re- 
sults are  tabulated  below: 


TABLE  4-2 

E(q)  FOR  FTNCTION  SHARING  CONFIGURATION 
RECOMMENDED  CONFIGURATION  MINIMAL  CONFIGURATION 


ITEM 

1985 

PEAK  HR. 

1995 

PEAK  HR. 

1995 

AVERAGE  HR. 

1995 
PEAK  HR, 

r 

. 10 

. 15 

.07 

. 15 

E(q) 

.002 

.003 

.001 

.003 

where  p = utilization,  E(q)  = expected  queuing  time. 

To  determine  E(w)  for  any  task  handled  by  the  input  processor, 
it  is  only  necessary  to  add  the  correct  E(q)  from  the  above 
table  to  the  calculated  service  time. 


A 
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4.1.4.J.2  lnteri)rocessor  Channel  Utilization  - 1995  Demand 
Capacity  (per  bus)  = 1 3M  bits/sec  = l.b25M  bytes/sec 
Peak  hour  bus  traffic  (bytes)  is  estimated  as  follows: 

1.  From  weather  retrieval  to  input  processor: 

454  PSBT  briefs  (3  7500  char/brief  = 3.41M  bytes/hr 

2.  To  route  processor  from  input  processor: 

454  PSBT  briefs  (3  500  char/brief  » 0.23M  bytes/hr 

3.  From  weather  retrieval  to  input  processor: 

152  Specialist  briefs  5000 

char/brief  “ . 76M  bytes/hr 

4.  To  route  processor  from  input  processor: 

152  Specialist  briefs  @ 500 

char/brief  » .08M  bytes/hr 

5.  Between  processors: 

monitor  messages  0 250  char/sec*  “ . 90M  bytes/hr 

6.  To  weather  retrieval  from  route  processor: 

606  route  briefs  0 1500  char/briefs  " ,91M  bytes/hr 

7.  From  weather  retrieval  to  input  processor: 

303  local  briefs  0 1500  char/briefs  « .45M  bytes/hr 

* Assumes  about  30  character/message,  8 messages/sec.  (Both 
estimates . ) 


4-22 


8.  To  weather  retrieval  from  Input  processor: 

T03  local  briefs  0 500  char/brief  = . 1 5M  bytes/hr 

9.  To/from  flight  plan  processor: 

415  flight  plans  (3  1000  char  each  » .42M  bytes/hr 


10.  Tt)/from  conin.  processor: 

189  aircraft  contact  messages  0 1000 

char,  each  = . 19M  bytes/hr 

11.  5,000  miscellaneous  messages  0 

500  char,  each  = 1 . 5M  bytes/hr 

12.  Weather  data  update  = .47M  bytes/hr 

9 . 4M  bytes/hr 
= 2611  bytes/second 


Bus  utilization  may  be  calculated: 


2611  bytes/i 
1.625  X 10^’ 


sec 


bvtos/sec 


.0016 


With  bus  utilization  so  low,  essentially  regardless  of  the 
queueing  model  assumed  it  will  have  no  effect  on  waiting  time, 
and  so  will  be  ignored  in  the  remainder  of  this  study. 
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4. 1.4. 2. 3 Route  Processor 


stiidleH  on  the  route  proceHBlnjj  proKram  now  running  on  the  ex- 
perimental PSBT  system  at  MITRE  have  shown  an  approximately 
linear  relationship  between  route  distance  and  number  of  instruc- 
tions executed  (instruction  ” 348K  + 180  x distance).*  The  minimum 
number  of  Instructions  is  about  348K,  and  the  maximum  about  750K. 
Added  to  this  are  11  disc  accesses,  which  may  be  assumed  to  take 
52.5/msec  each,  for  a total  of  about  .6  seconds.  At  262K  Instr/ 
sec,  this  yields  for  the  total  route  processing  time: 


348K  ^ ^ 750K  , 

+ .6  sec  it<  + .6  sec 


262K 


262K 


1.928  sec  <t<  3.463  sec 

Based  on  the  average  route  distance  for  a route  oriented  briefing 
of  480nra,**  the  average  time  for  a route  processing  task  will 
be : 


348K  + (180) (480)  . , 

262^^ 


2. 26  sec. 


No  exact  data  on  the  distribution  of  route  distances  are  avail- 
able, but  FSS  specialists  estimate  that  85%  are  less  than  500nm, 


* See  Appendix  B for  details. 
**  See  Appendix  B,  Section  2.5. 
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s(i  1!  wi'  h.jvi’  d 1 s t r i bui  i on  which  closely  restricts  the  briefings 
to  the  .iver.i)’,e,  that  will  be  a reasonable  estimate  for  the  pur- 
poses of  this  queueing;  analysis. 

The  distribution  chosen  to  represent  the  distribution  of  route 
proce-^slnK  service  times  Is  an  F.rlang-10  distribution,  which  is 
a rt'nservat  1 ve  assumption  and  so  will  put  a reasonable  upper 
limit  on  queueing  time  and  waiting  time.  The  route  processor 
is  assumed  to  work  on  only  one  task  at  a time,  and  processing  is 
lumped  with  disk  I/O  here  for  the  purpose  of  calculation.  The 
route  processor  may  be  modeled  by  an  M/E^^/l  queueing  system,  for 
which  we  have  the  following  parameters: 

For  Frlang-10  distribution  of  service  time: 

F (x)  = a = 2. 26  sec 

■’k+l  211  2 2 

E(x")  = ^ [E(s)]^  = ~ [E(x)]^  = l.la'^  = 5.618 

k 10 

The  following  cases  of  Interest  may  be  distinguished: 

I 1985  Peak  hour,  2 route  processors 
II  1995  Peak  hour,  2 route  processors 
III  1995  Average  hour,  2 route  processors 
IV  1995  Peak  hour,l  route  processor. 

For  Case  IV,  the  mean  waiting  time  (”  service  time  + queueing 
time)  can  be  calculated,  using  the  following  formulae  for  a 
single  server  queue: 
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» mean  service  time  « s 
X = mean  arrival  rate  per  second  (»  number/hr 

n ' Xn  system  utilization 

2 2 
K(x  ) = 1.1a 


3600) 


Wq  « XE(x  ) 
2(l-p) 


mean  waiting  time  in  queue 


E(w)  = Wq  + a = mean  waiting  time 


For  cases  I,  11  and  111,  the  formulae  for  a multiserver  queueing 
system*  must  be  employed.  This  is  because  in  each  of  these  cases 
there  are  assumed  to  be  two  processors  available  for  route  pro- 
cessing, and  the  system  will  assign  tasks  to  them  as  a function 
of  their  workload.  The  route  processors,  in  other  words,  form 
a two-server  system.  With  the  same  parameters  as  before,  we 
def Ine 


(n- 1 

E 

n=0 

(mp)" 

n! 

m 

n:  / 

E 

^n-O 

where  m = number  of  servers.  Then  the  probability  that  all  are 
busy  is  B,  given  by 

B - 1-2 
I - pz 


* Systems  Analysis  for  Data  Transmission,  James  Martin,  Prentice 
Hall:  Englewood  Cliffs,  1972,  p.  451-461. 


4-26 


Mean  waiting  time  In  queue  is 


and 

E(w)  = W + a 

q 

The  results  of  carrying  out  the  above  calculations  for  the  four 
cases  are  summarized  in  Table  A-3. 


TABLE  4-3 

ROUTE  PROCESSING  SERVICE  TIEES  FOR  FUNCTION  SHARING  CONFIGURATION 


CASE  I 

II 

III 

IV 

Mean  number/hour/ 

207 

30  3 

152 

606 

processor . 

a 

2.26 

2.26 

2.26 

2.  26 

X 

.058 

.084 

.042 

.168 

0 

. 1 30 

. 190 

.095 

. 360 

2 

E(x  ) 

5.618 

5.618 

5.618 

5.618 

B 

.0299 

.0608 

.0166 

- 

W 

.0214 

.0467 

.0114 

. 763 

q 

E(w) 

2.281 

2.  307 

2.271 

3.023 

Due  to  the  relatively  low  number  of  disk  accesses  per  hour,  for 


'•1.  1 . ‘4,  2. 4 Weather  Retrieval 


Weather  retrieval  for  route  oriented  and  local  briefings  is 
envisioned  as  working  in  the  following  manner.  WTien  a request 
for  one  of  these  two  types  is  input,  the  system  assigns  highest 
priority  to  retrieving  and  displaying  the  first  page  of  the 
weather,  since  the  rest  of  the  pages  can  be  retrieved  while  the 
specialist  or  pilot  is  reading  the  first  page.  It  is  estimated 
that  either  will  take  at  least  five  seconds  to  scan  the  page. 

The  remaining  weather  data  is  then  retrieved  and  sent  to  the 
terminal  I/O  processor  to  be  ready  for  display  when  the  re- 
questor is  ready. 

One  further  matter  must  be  analyzed  regarding  the  first  page  of 
displayed  weather  data.  According  to  the  FSS  specif ication,  the 
specialist  or  pilot  has  three  choices  as  the  first  item  in  his 
briefing:  (1)  graphics,  (2)  FA's,  (3)  alphanumeric  briefing. 

There  are  of  course  no  statistics  available  on  how  often  each  of 
these  will  be  selected,  but  a reasonable  assumption  is:  graphics, 
60%,  fa's,  20%;  and  alphanumeric  briefing  (SA's  first),  20%. 
fsing  the  data  in  Appendix  B,  and  assuming  two  disk  accesses  for 
retrieval  of  an  AFOS  chart,  this  yields  a weighted  average 
number  of  instructions  of  about  16K,  and  between  four  and  five 
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ill'il'  .K  I I'ssfH . Hi-ri',  1 f)K  iDHtructlona  und  five  disk  .u-cobhi'h 
will  be  assuiTifd. 

In  view  of  the  numerous  functions  the  weather  retrieval  proces- 
sor must  perform,  some  of  which,  as  indicated  above,  are  quite 
lengthv,  optimum  performance  can  be  realized  only  with  a 
prioritv  queueing  scheme. 

Here  the  number  of  tasks  is  divided  into  nine  categories,  and  an 
M/C/l  preemptive-resume  queueing  model  assumed.  The  categories 
are  depicted  in  Figure  4-7. 

This  scheme  has  been  designed  to  give  highest  priority  to  re- 
trieval and  output  of  the  first  page  of  a briefing,  since  this 
time  will  have  most  effect  on  overall  system  response  time.  As 
explained  above,  it  is  assumed  that  a specialist  or  pilot  will 
take  at  least  several  seconds  to  scan  the  first  page,  so  re- 
trieval and  output  of  the  remainder  of  the  items  in  the  briefing 
is  relegated  to  lowest  priority. 

As  before,  worst-case  or  near  worst-case  assumptions  were  made 
concerning  service  time  distribution,  so  that  the  calculated 
waiting  time  estimates  should  be  conservative.  Data  for  the 
number  of  instructions  for  items  in  each  category  were  taken 
from  Tables  B-1  and  B-2. 
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(1)  Processor  status  messages 
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CATEGORIES  IN  PREEMPTIVE-RESUME  WEATHER  RETRIEVAL  QUEUEING  SCHEME 


In  order  to  evaluate  the  mean  waiting  time  for  Items  In  each  of 


these  categories,  it  is  necessary  to  know  i (mean  arrival  rate), 
(mean  service  time),  and  (second  moment  of  service 

time)  for  each.  The  last  two  items,  of  course,  remain  unchanged 
regardless  of  i,  l.e.,  regardless  of  the  number  of  briefs/pro- 
cessor given  per  hour.  The  usual  four  cases  are  distinguished 
below:  (1)  two  processors,  1985  peak  hour  load;  (II)  two  pro- 
cessors, 1995  peak  hour  load  (which  corresponds  to  one  processor 
average  hour  load);  (III)  two  processors,  1995  average  hour  load; 
and  (IV)  one  processor,  1995  peak  hour  load.  Relevant  data  for 
the  cases  are  summarized  below  (demand  figures  from  Appendix  A). 

Case  I;  two  processors,  1985  peak  hour  load,  per  processor  demand 
Route  Briefs:  207 
Local  briefs:  101 

Case  II:  two  processors,  1995  peak  hour  load,  per  processor  demand 
Route  briefs:  103 
Local  briefs:  154 

Case  111:  two  processors,  1995  average  hour  load,  per  processor 
demand 

Route  briefs:  152 
Local  briefs:  7-7 
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Case  IV:  one  processor,  1995  peak  hour  load 


Route  briefs;  606 
Local  briefs:  307 

In  Table  4-4,  the  nine  individual  categories  are  given  in  the 
left  column,  together  with  their  respective  and  to 

the  right,  the  corresponding  value  of  X is  given  for  each  of 
rhe  four  cases. 

A preemptive-resume  queuing  model  is  assumed  here,  for  which 
the  relevant  formuale  are  given  below:* 


2(1  - Uj) 


Results  of  the  queueing  calculations  are  given  in  Table  4-5 
for  the  nine  categories  in  each  of  Che  four  cases.  Also  given 
is  the  service  time  for  each  item,  so  that  a direct  comparison 
may  be  made  with  the  waiting  time  calculated.  All  numbers  are 
given  to  three  significant  figures. 


* Allen,  o£.  ci t . , p.  186-187. 
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lABLK  4,-4 


VAl.’i:S  OK  * (MP'.AN  ARKIVAI.  RATE)  FOR  DIFFERKNT 
LOADS  IN  PRKKMPTIVE  RESIW:  WEATHER  RETRlEVAl.  QUELEINO  SCHEMt: 


(ATECU^HY 

1.  Froc4*sKi'r  status 
mesHa>;t*H  7S 
instr  f*a.  Service 
I lni€*  asHumed  con- 
st .itU 

/*'-  .000  3 sec 


(2) 


-8  2 
10  sec 


2. 


Data  base  update* 
fo  SOO  instr  each 
E^  service  time 

distribution 


(1) 

•1 

(2) 

•'I 


.0019  sec 
4.9  X 10  ^sec 


3.  Output  to  other 
processors,  1st 
pa^e  & 5000  instr 
each** 

Ej  service  time 
dis  t rlbut Ion 

- .01908  sec 

- .00049  sec^ 


CASE 


I 

1 1 

III 

IV 

28800/hr  - 
8/sec  " Xj 

28 800/ hr  - 
8/Hec  - Xj 

28800/hr  - 
S/sec  - Xj 

21600/hr  - 
6/sec  - Xj 

90/hr  -* 
.025/sec  = 

90/hr  - 
.025/sec  “ 

*2 

90/hr  ■ 
.025/sec  - 

^2 

90/hr  - 
.025/sec“ 

^2 

207  + 101  - 
308/hr  - 
,0856/sec  " 

303  + 154  • 
457/hr  - 
. 1269/.9ec  » 

*3 

152  + 77  - 
229/hr  - 
.06361/sec  - 

^3 

606  + 307/hr 
913/hr  - 
.2536/sec  ■ 

* This  assumes  the  special  method  of  Weather  data  base  management  described  In 
Section  4.1.3.  However,  If  each  machine  performed  all  the  base  management 
functions,  the  effect  would  be  to  cause  response  times  for  items  2-7  to  Increase 
bv  about  25-30!t,  and  items  8 and  9 by  somewhat  more  for  Case  II.  With  the 
method  chosen  here,  90  updates  per  hour,  or  about  one  every  40  secons  Is  as- 
sumed. But  this  frequency  can  be  increased  by  a factor  of  three  to  four  with 
essentially  no  impact  on  response  time. 

**  Allows  ten  Instructions  executed  per  character. 
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TABLK  U~U 
(CONTD) 


C-A 1 E(.<)KY 


I/O  roadv  list  .ind 
trjr<»sa^;,f  prore‘iS  iriK 
- 1st  p.iKe 

16000  In.str  each 
Fj  service  tline 


distribution 

- .0612  sec 

“(2)  2 
■ ^ ' =■  .00497  sec 


r ornmini  cat  i ons  - 
from  otht r proces- 
sors 

^ lOK  Instr  each 
service  time 


d ist  ribut ion 

(1) 


- .0382  sec 


(2)  nmiT  ^ 

■ .00222  sec 


6.  Output  to  other 
processors  - rest 
of  route  brief* 

/<>  64K  instr  each 
service  time 

dist  ribut ion 

9//1 

“ .2441  sec 

r> 

( 2)  2 
^ - .0796  sec 


7. 


Output  to  other 
processors  - rest 
of  local  brief 
^ lOK  Instr  each 
F,^  service  time 

distribution 

- .0382  sec 


(2) 

'■7 


.00194 


2 

sec 


I _ 

11 

III 

IV 

308/hr  ■= 

437/hr  - 

229/hr  - 

913/hr  * 

.0836/sec  ■ 

. 1 269/ sec  - 

.06361/Bec  « 

.2536/sec  - 

'4 

108/hr  - 

457/hr  - 

229/hr  - 

9n/hr  • 

.0856/sec  * 

. 1 269/sec  “ 

.06161/sec  * 

. 2536/ sec 

> 

5 

5 

5 

5 

207/hr  - 

303/hr  - 

152/hr  - 

606/hr  * 

.0575/9ec  • 

.0842/8ec  • 

.0422/sec  - 

.1683/sec 

> 

> 

X 

6 

6 

6 

6 

101/hr  - 

154/hr  • 

77/hr  - 

307/hr  • 

.0281/sec  - 

.04278/sec  - 

,02139/sec  ■ 

.08528/sec 

X, 

X 

X , 

7 

7 

7 

7 

* Assumes  weighted  average  of  12.75  additional  pages  based  on  25X  * 75% 
Specialist  - Pilot  self-brief  split. 
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TABLK  4-4 
(CONTD) 


1 

IJ 

III 

IV 

H.  I/O  rp.idv  lint  and 

207/hr  - 

30  3/hr  - 

152/hr  - 

606/hr  - 

tnpssaKe  process Inji; 

.0575/aec  ■ 

.0842/8ec  ■ 

.0422/sec  • 

.1683/8ec  - 

- rest  of  route 

A 

X„ 

X„ 

brief 

^ b7lK  Instr  each 

1 . service  time 

distribution 

*2.56  *ec 

^ .Hi*  sec^ 

8 

8 

8 

8 

I/O  readv  list  and 

101/hr  - 

154/hr  • 

77/hr  • 

307/hr  - 

messaKe  processing 

.0281/sec  ■ 

.04278/sec  - 

.02139/bec  - 

.08528/sec  ■ 

- rest  of  local 

X„ 

brief 

76K  Instr  each 
service  time 

distribution 

• .290  sec 

• .112  »ec^ 

9 

9 

9 

9 
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MI.AN  CPU  WAITING  TIMI'S  FGR  Fl’NCTION  SHARING  CONFI GIR,\TIGN'S  (SF.CONHS) 


I 


o 

o 

o 

a 

ro 

r-H 

ro 

O 

r-i 

o 

•-H 

O 

•~-i 

m 

ITj 

O 

o 

r-H 

sD 

in 

nD 

r ; 

< 

O 

o 

O 

O 

o 

O 

• 

O 

• 

• 

• 

• 

• 

• 

• 

-t 

<r 

f— 1 

t— I 

o 

c 

c 

f-H 

vC 

r>-. 

O 

C 

♦-H 

O' 

»— • 

CO 

o. 

i-H 

nC 

m 

o 

o 

nC 

m 

00 

r— 4 

o 

o 

o 

o 

O 

JN 

o 

• 

nO 

'O 

• 

• 

• 

• 

• 

• 

• 

fN 

• 

H-l 

o 

o 

o 

m 

O' 

(N 

O' 

rvj 

c^ 

O 

1—4 

o^ 

»— i 

C^ 

m 

m 

sO 

c 

o 

sD 

m 

m 

<N 

o 

o 

o 

o 

O 

rsj 

O 

• 

u 

• 

• 

• 

• 

• 

• 

• 

c 

o 

o 

cr 

CSJ 

On 

O 

C 

»— • 

O' 

00 

o 

r-4 

ON 

r*^ 

o 

o 

I—* 

vO 

m 

m 

ON 

< 

o 

o 

o 

O 

o 

eg 

O 

• 

• 

• 

• 

• 

• 

• 

rj 

• 

E TIME 

c 

o 

m 

o 

O' 

r<j 

C'J 

rsi 

u 

C 

i-H 

O' 

00 

<r 

X 

sO 

o 

►—4 

O 

o 

sC 

m 

<r 

m 

m 

ON 

C 

o 

o 

o 

c 

CN 

O 

• 

nj 

tc 

UJ 

00 

■ 

CN 

OO 

z 

o 

tij 

t-4 

u. 

Ou 

u. 

u. 

H 

o 

H 

tu 

Ui 

U3 

< 

z 

< 

»— 1 

p- • 

pH 

PH 

00 

C 

UJ 

UJ 

u 

} X 

1 X 

X 

X 

UJ 

O 

O 

X 

t-H 

P3 

oa 

(JL. 

OQ 

03 

to  o 

< Ir 

< 

to 

H 

O 

o 

< 

a.  b 

Om 

U3 

1:3  UJ 

b kJ 

UJ 

hJ 

>- 

H to 

• 

U 

y 

x H 

a.  < 

H 

H 

H 

< 

zc 

< to 

03 

H 

O 

2 

P S 

H (J 

to 

to 

a 

s 

H-  W 

• 

00  Zj 

oo 

X 

O 

^ o 

o 

O 

c 

C 

UJ 

H 

to  X 

a 

o 

pH 

Ou 

CJ 

o oe: 

O pJ 

S 

K 

< 

• 

• 

• 

• 

• 

• 

• 

. 

• 

U 

(N 

m 

m 

r«. 

X 

ON 

4-36 


lA 


A t fw  comments  on  this  Table  are  In  order.  As  I terns  8 and  9 in 


the  last  column  show,  the  deslKii  represented  by  Case  IV  (1 
weather  retrlev.il  processor)  begins  to  show  signs  of  performance 
de>rad.it  liin  under  expected  peak  hour  loading.  However,  that 
'e,  r.idatlon  is  relatively  minor,  and  indicates  that  with  the 
rec  crnir.ended  dt-sign  and  equivalent  load  (Case  II),  there  is  a 
considerable  margin  of  safety  in  the  form  of  reserve  capacity. 

■ 1 . A . . 5 Disk  l.juem'ing 

To  analyze  the  queues  associated  with  disk  accesses,  the  same 
four  cases  as  above  will  be  considered,  and  for  each  case,  the 
expected  queueing  time  assuming  1,  2,  3 or  4 disks  share  the 
load  will  be  determined. 

Based  on  Tables  B- 1 and  B-2  from  Appendix  B,  the  total  number 
of  disk  accesses  per  hour  for  each  case  can  be  determined  by 
sumr.ing  the  number  for  each  briefing  type,  and  multiplying  by 
the  number  of  briefings  of  each  type  from  Appendix  A.  In  ad- 
dition, an  average  of  360  accesses  per  hour  per  disk  are 
assumed  for  data  base  maintenance,  but  as  will  become  apparent, 
that  number  could  be  several  times  larger  with  no  appreciable 
effect  on  queueing  time,*  A sample  calculation,  that  for 
Case  IV,  is  as  follows: 

* -See  Reference  1 in  Appendix  C;  360  one  sector  transfers/hour 
corresponds  to  about  184K  bytes/hour;  or  40%  of  estimated  peak 
hour  update  traffic. 
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peak  hciur  rmile  briefs:  bOb 
Disk  accesses/brief  (weather  portion):  82 


I'roduct : 49b92 


199^  peak  hour  local  briefs:  307 

Disk  Accesses/brief  (weather  portion):  30  Product:  9210 

Total  disk  accesses:  58902  + 360(accesses  for  d.b.m.)  = 59262 
The  expected  load  per  processor  (excluding  data  base  maintenance) 
is  shown  in  Table  4-b  below. 

TABLE  4-6 

DISK  ACCESSES  PER  HOUR  FOR  WEATHER  RETRIEVAL  L'NDER 
DIFFERENT  LOADS 

I II  III  IV 

NUMBER  OF  ACCESSES  20004  29466  14733  58902 

The  following  assumptions  concerning  the  disks  will  be  made 
(performance  slightly  below  that  of  IBM  3330  disk  drive): 

1.  All  are  Identical,  moving-head  type 

2.  Rotational  speed  is  2400  RPM 

3.  Average  seek  time  is  37.5  msec 

4.  Transfer  rate  is  200K  bytes/sec 

5.  There  are  10  sectors  per  track 

6.  Transfers  are  one  sector  which  is  512  bytes  (1-2% 
of  transfers  may  be  up  to  one  track,  but  this  will  have 
essentially  no  effect  on  mean  response  or  queueing  time) 


A 
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7.  There  Is  no  waiting  time  for  the  DMA 
An  average  transfer  then  will  take 

37.5  msec  (seek)  + 12.5  msec  (latency)  +2.5  msec 
(read  1 sector)  = 52.5  msec  ( = a) 

For  the  purposes  of  this  analysis,  all  three  parts  of  the  disk 

operation  will  be  lumped  together  and  service  time  variance  will 
-2 

be  assumed  to  be  s*"  (i.e.,  exponential  distribution)  which  is 
certainly  a worst  case  assumption.  In  case  a disk  transfer  is 
blocked  due  to  a busy  channel,  the  disk  must  wait  another  25  msec 
before  reattempting  its  transfer.  This  need  not  be  considered, 
however,  if  channel  utilization  is  sufficiently  low.  For  one 
sector  transfers,  DMA  utilization  is  summarized  in  Table  4-7  for 
the  four  cases,  assuming  1-4  disks.  A sample  calculation  is  as 
f o 1 lows : 

Case  IV,  1 disk  = 58902  + 360  = 59262  accesses/hr 
X .0025  sec/read  x hr/3600  sec  = .04115 

TABLE  4-7 


DMA  LTILIZATION  FOR  WEATHER  RETRIEVAL  PROCESSORS 


M-MBER  OF  DISKS 

CASE  1 

CASE  II 

CASE  III 

CASE  IV 

1 

.01414 

.02071 

.01048 

.04115 

.00720 

.0i048 

.00537 

.02070 

3 

.00488 

.00707 

.00366 

.01388 

4 

.00372 

.00537 

.00281 

.01048 
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As  Is  apparent  from  the  table,  utilization  Is  well  bt'low  2%  In 
all  < ases  likely  to  be  of  Interest,  and  below  1%  In  most,  so  we 
shall  continue,  assuminit  a multiserver  queuelnR  system.  The 
equations  used  are  the  same  as  those  employed  In  the  route  pro- 
cessor estimation.  Cases  I,  II  and  III. 


W 

<1 


E_ 

2m 


and 


s + 0 


2 

s 


/ s 


1 - P 


E(w)  = W + a 

q 


Bs 

m(l  -P) 


for  o = s, 
s 


Table  4-8  summarizes  Important  data  for  each  of  the  four  cases 
selected. 

Based  on  these  data,  the  number  of  disks  per  weather  retrieval 
processor  will  be  assumed  to  be  three  for  a two  processor  system, 
and  four  for  a one  processor  system,  since  this  will  provide  for 
extremely  short  queues  and  a wide  margin  of  safety  in  case  of 
higher  loading  due  to  a failed  disk  or  higher  than  anticipated 
demand . 


4. 1.4. 3 Estimation  of  Total  Response  Time 

TTie  response  time  for  route  and  local  briefings  for  two  con- 
figurations under  different  loading  conditions  can  now  be 
estimated.  Response  time  is  considered  to  be  the  Interval  between 
depression  of  the  ENTER  key  after  the  last  item  of  data  is  input. 
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TAliLK  4-H 


>T/VN  DISK  ACCKSS  WAITING  TIMES  TOK  DIFFERENT  LOAD 
rONPITIONS  ANT)  DIFFERENT  NTMBERS  OF  DISKS/PROCESSOR 

AVG.  ACCESSES/ 


NO.  OF 

DISKS(m) 

E(w) 

W 

9 

B 

P 

DISK/ HOUR 

CASE 

1 ; 2 WX 

RETRIEVAL  PROCESSORS, 

1985  PEAK  LOAD 

1 

.0747 

.0222 

. 2970 

. 2970 

20364 

n 

.0537 

.0012 

.0397 

.1511 

10362 

3 

.0520 

7.  7 X lO”^ 

. An40 

.1025 

7028 

.4 

.0525 

4. 5 X lO"” 

.0003 

.0782 

5361 

USV. 

II:  2 wx  RETRIEVAI.  PROCESSORS, 

1995  PEAK  LOAD 

1 

.0929 

.0404 

. 4 350 

.4  350 

29826 

0 

.0546 

.0021 

.0794 

. 2201 

15093 

) 

.0527 

.0002 

.0111 

.1485 

10182 

4 

.0525 

1.8  X lO" 

.0012 

.1127 

7727 

CASE 

III : 2 WX  RETRIEVAL  1 

PROCESSORS, 

1995  AVERAGE  LOAD 

1 

.0673 

.0148 

.2201 

.2201 

15093 

2 

.0532 

.0007 

.0228 

.1127 

7727 

3 

.0525 

3.3  X lO"^ 

.0018 

.0769 

5271 

4 

.0525 

1.5  X 10* 

. 000 1 

.0590 

4043 

CASE 

IV:  I WX  RETRIEVAL  PROCESSOR,  1995  PEAK  LOAD 

1 

. 386  7 

. 3342 

.8642 

.8642 

59262 

2 

.0647 

.0122 

. 2635 

.434  7 

29811 

3 

.0541 

.0016 

.0652 

.2916 

19994 

4 

.0527 

.0002 

.0133 

.2200 

15086 

p ” DISK  ITILIZATION 
B « MIXTIPLE  SERITR  FACTOR 
W - QITUEING  TIME 

q 

E(w)  - EXPECTED  SERVICE  TIME 
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until  the  first  character  of  the  response  appears  on  the  entering 


terminal.  Ttie  two  configurations  considered  are:  (1)  tlie  recom- 
mended conf Iguratlon,  consisting  of  two  weather  retrieval  proces- 
sors .ind  two  route  processors,  and  (2)  a minimal  configuration, 
consisting  of  one  weather  retrieval  and  one  route  processor. 

The  following  sections  explain  how  each  estimate  is  m.ade. 

■«.1.4.3.1  Route  Briefing,  First  Page 

1.  Input  request  - assumed  to  require  processing  of  lOK 
machine  Instructions,  the  time  for  which  is  estimated  by: 

lOK  X 1.6  / 420K  + E(q) 

input  request  ) 

system  over-  

head 

machine  speed  (IPS)  

Queueing  delay  from  Sec.  4. 1.4. 2.1 

2.  Route  Processing  - times  from  Table  4-3  used  directly. 

3.  Weather  Retrieval  Processing:  CPIT,  first  page  - items 
(3),  (4)  and  (5)  from  Table  4-5. 

4.  Disk  accesses  - first  page,  average  of  five  assumed, 
average  time  for  each  from  Table  4-8,  overlapping  of  seeks 
and  reads  assumed  to  reduce  total  time  by  a factor  of  two. 
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iiiitjiiit  - tlrst  pane,  roqulrlnn  '<K  machliu-  Inst  rui  t Ions 

fi.r  formattlnn,  protocol,  ct(  . , the  total  t Init-  for  which  is 
5K  X l.h  / 420K  + i:(q) 

Ciitput ^ 

SvstPir.  Overhead  — — ‘ 

Machine  Speed  (IPS)  — 

Queueinn  delay  from  Sec.  4. 1.4. 2.1 

h . 1 nterprocessor  communications  - a minimum  of  four 

would  be  required  for  output  of  the  first  page,  but  al- 
lowance will  be  made  for  six  in  case  of  problems.  TAMDEM 
has  stated  that  each  such  transaction  requires  about 
seven  msec. 

4. 1.4. 3.2  Local  Briefing  - First  Page 

Same  as  above,  except  item  (2)  deleted,  and  only  four  inter-  > 
processor  messages  assumed. 

4. 1.4. 3. 3 Route  Briefing  - Remainder 

1.  Weather  Retrieval  Processing:  (IPU,  all  other  pages  - 
items  (6)  and  (8)  from  Table  4-5. 

2.  Weather  Retrieval  Processing:  Disk  accesses,  all  other 
pages  - average  of  77  assumed,  average  time  for  each  from 
Table  4-8,  overlapping  of  seeks,  etc.,  assumed  to  reduce 
total  time  by  a factor  of  two. 
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3.  Output  - single  page,  same  as  (5)  under  "Route  Briefing, 


first  page,"  above. 

4.  Interprocessor  Communication  - maximum  of  two  required. 

4.  1.4. 3.4  Local  Briefing  - Remainder 

1.  Weather  Retrieval  Processing:  CPU,  all  other  pages  - 
items  (7)  and  (9)  from  Table  4-5. 

2.  Weather  Retrieval  Processing:  Disk  access,  all  other 
pages  - average  of  25,  average  time  for  each  from  Table 
4-8,  overlapping  of  seeks,  etc.,  assumed  to  reduce  total 
time  by  a factor  of  two. 

3.  and  4.  - Same  as  Route  Briefing. 

4. 1.4. 3.5  Route  Briefing  - Calculations  and  Final  Results 

1.  First  Page  - Total  response  time  for  output  of  first 
page  of  route  oriented  briefing  is  given  in  Table  4-9. 

2.  Remainder  of  Pages  - Total  time  until  rest  of  pages 
in  route  briefing  are  available  for  display  is  summarized 
in  Table  4-10. 
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TAHl.f-: 


Mi./v;  RrsHi) 

NSE  TIMES  (SECONDS) 

FOR  FIRST  PAGE 

OF  ROUTE 

OKII.MKD 

BRIEEING  IN  FUNCTION  SHARING  CONFIGURATION 

RECOMMEN 

DEI)  CONMGURATION 

>nNIM/M, 

CO.NFIGUIWTION 

CASE  1 

CASE  I I 

CASE  III 

CASE  IV 

1985 

1 99  S 

1 99  5 

1995 

1 :kv 

PEAK  HOUR 

PEAK  HOUR 

A VC.  HOUR 

PEAK  HOUR 

INTI'T  KKiJITST 

.OAO 

.041 

.0  39 

.041 

Hin'IK  I'ROCKSSING 

2.281 

2.  307 

2.271 

3.02  3 

1.  w>:  RKTFIKVAI. 

.120 

.120 

.119 

. 122 

•i.  [)!SK  I/O 

. I 32 

.132 

.131 

. 1 32 

5.  olTI’n 

.021 

.022 

.020 

.022 

h.  IMKRPROtKSSOR 

.042 

.042 

.042 

.04  2 

roiAI.S  (SfTON-pS) 

2.636 

2.664 

2.622 

00 

: 

! 

i 

1 

TABLE  4 

-10 

MAN  TIMS 

FOR  RETRIEVAL  OF  REMAINDER  OF  DATA 

FOR  ROUTE 

ORIENTED 

BRIEFING  IN  Fl-NCTION  SHARING  CONFIGURATION 

RECOMMENDED  C0NFIGUR/\TI0N 

MINIFWL 

CONFIGURATION- 

CASE  I 

CASE  II 

CASE  111 

CASE  IV 

1985 

1995 

1995 

1995 

I T EM 

PEAK  HOUR 

PEAK  HOUR 

AVG.  HOUR 

PEAK  HOUR 

1.  WX  RETIUEVAI. 

3.240 

3.  503 

3.  109 

4.871 

2.  DISK  I/O 

2.02S 

2.029 

2.021 

2.029 

T.  OI'TI’I  T 

.021 

.022 

.020 

.022 

A.  INTERTROCF.SSOR 

.014 

.014 

.014 

.014 

TOTALS  (SECONDS) 

5.  300 

5.568 

5.  164 

6.936 
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. I . . 3 . *•'  I.oc.ll  Brlcl'in^  - C.tirulalton.s  anJ  I'ln.il  Ke.sulC.s 


1.  Kirst  - Total  response  time  for  output  of  first  page 

til  local  briefing  is  given  in  Table  4-11. 

Rct::.iin(!«'r  of  Pages  - Total  time  until  rest  of  pages  in  local 
briefing  are  available  for  display  is  summarized  in  Table  4-12. 

4. 1.4. 3. 7 Variance  of  Response  Time 

In  general,  complex  queueing  models  such  as  this  will  not  predict 
response  time  variance  sufficiently  accurately  to  be  relied  upon.* 
However,  Table  4-13  shows  an  estimate  for  output  of  the  first 
page  of  the  data,  given  the  recommended  configuration,  1995  de- 
mand, peak  hour,  assuming  the  central  limit  theorem  can  be  in- 
voked to  give  results  that  are  at  least  approximately  correct, 
riven  a normal  distribution,  with  mean  u = 2.664  (from  Table 
4-d)  and  standard  deviation  a = .8  (Table  4-13),  approximately 
85T  of  all  route  briefings  will  take  less  than  N'  + lo  = 3.5 
seconds,  better  than  95-(  will  take  less  than  M + 2o  = 4.3 
seconds,  and  99%  will  take  under  M + 3o  = 5.1  seconds. 

4.  1.4.4  Response  limes  for  Flight  Plans,  Aircraft  Contacts, 
and  Miscellaneous  Messages 

The  response  tines  for  flight  plans,  aircraft  contacts  and 
miscellaneous  messages  is  estinuited  in  the  following  sections. 

W.  Chang,  "Single  Server  Queueing  Process  in  Computing  Systems," 

IB.M  Systents  Journal,  No.  1,  1970,  p.  62. 
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tabu:  4-11 


it/v,  RESi'oNSi:  tim;s  for  first  paof:  of  local 
brieft::(;  in  function  sharinc  conficuration 

MINIMAL 

RECOMMENDED  CONFICURiUlON  CONFIGURATION 


ITEM 

ISHS 

PEAK'  HOUR 

1995 

PEAK  HOUR 

1995 

A VC.  HOUR 

1995 

PEAK  HOUR 

INPUT  REQLT.ST 

.040 

.041 

.039 

.041 

2.  L'v  RETRIEVAL 

. 120 

.120 

. 119 

. 122 

).  DISK  I/O 

.112 

. 1 32 

.1  31 

. I 32 

4 . OUTPUT 

.021 

.022 

.020 

.022 

S.  INTERPROCESSOR 

.028 

.028 

.028 

.028 

TOTAi.S  (SECONDS) 

. 141 

. 343 

. 317 

. 345 

TABLE  4-12 


MEAN 

RESPONSE  TIMES 

FOR  RETRIEVAL 

OF  REMAINDER 

OF 

DATA  FOR 

LOCAL  BRIEFING 

IN  FUNCTION 

SHARI.NG  CONFIGURflTION 

MINI.MAL 

RECOMMENDED  CONFIGURATION 

CONFIGURATION 

1985 

1995 

1995 

1995 

1 Ti.M 

PEAK  HOUR 

PEAK  HOUR 

AVG.  HOUR 

PEAK  HOUR 

1.  WX  RETRIEVAL 

.819 

1.204 

.6  54 

4.280 

2.  DISK  I/O 

.658 

.659 

.656 

.659 

i.  OUlPUT 

.021 

.022 

.020 

.022 

4.  INTERPROCESSOR 

.014 

.014 

.014 

.014 

TOTALS 

1.512 

1. 899 

. 344 

4.975 
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IMTKVfx)  * x^) 
porn  PROCKSSINT 
'..'X  PITPirVAI*  ITFX  n) 
iiff:  (U) 
iTi;r;  (^) 

iUSK  I/O** 

iHiriT  (v(>:j  = x‘) 

k.th'Profkssok  f:oMM. 

DISTHIBl'TION  ASSLTIKD  TO 
.*':'-’-'riN(.  v<x)  » (F.(X)) 
VfCX)  * r^V(Y)  MiERE  (. 


TABLE  A- 13 

RESPONSE  TIME  VARI/VNCE 


x’  V(x) 


3.  36 

X 

io‘^ 

1.68 

X 

10-' 

1.68  X 

10-' 

5.618 

5.  1 1 

. 511 

4.92 

X 

10-^ 

).6'‘ 

X 

10-“ 

1.2  1 X 

10-^ 

5.11 

X 

10*^ 

3.83 

X 

ur  ’ 

1 .28  X 

10-' 

2.  31 

X 

10-' 

1.54 

X 

10-  ' 

7.7  X 

10-“ 

1.25 

X 

10"' 

1.74 

X 

lo"-’ 

1.075  X 

K)- 

9.68 

X 

10-^ 

4.84 

X 

10-“ 

4 , 84  X 

lo-'* 

1.  76 

X 

10"' 

I.  76 

X 

10-' 

n 

.62  3 > 

.789  “0  .8 


BE  THAT  IN  TABLE  A-4 
FOR  SINGLE  ACCESS  AND  fSING  EoKjn  LA 
* 2.5 
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...  1 . 


1 Miscfl  IniK'ous  Mess.iges  and  Aircraft  Cont.'ict.s 


y.isce  1 l.inecnis  messages  and  Aircraft  Contacts  arc  assumed  handled 
bv  the  input  processor  alone,  with  the  following  breakdown  of 
s t eps  ; 

Aircraft  Contact 

Processing  20K  instructions 

Disk  Accesses  2 overlapped 

Miscellaneous  Messages 

Processing  1 OK  instructions 

Disk  Accesses  5 overlapped 

hefore  response  time  can  be  calculated,  disk  service  time  must 
be  estimated.  For  1995,  peak  hour,  the  number  of  accesses  is; 
Aircraft  contacts;  189  ^ 2 = 378 

I.ogging  A500  0 2=  9000 

Miscellaneous  3000  05=  15000 

24378  or  about  24,000. 

For  an  average  hour,  1995,  the  number  will  be  about  1/2  of  this, 
or  12,000;  and  for  1985,  peak  hour,  the  number  will  be  2/3  of 
24,000  or  about  16,000.  The  same  Tables  as  in  Section  4. 1.4. 2. 5 
nu'iv  be  constructed,  except  here  Cases  II  and  IV  are  the  same, 
since  both  iiave  the  same  load  and  same  number  (one)  of  input 
processors.  The  calculations  are  summarized  in  Table  4-14. 
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TABLE  4-14 


Ml'AN  DISK  ACf'ESS  WAITING  TIMES  FOR  DIFniRENT  LOAD 
CONDITIONS  /VND  DIFFERENT  NX'MRER  OF  DISKS/PROCESSOR 


CASE  I : 

RECO.MMENDED 

CONFIGURATION, 

1485 

Plj\K 

LOAD 

M..  OF 

AVG.  ACCESSES/ 

DISKS  ^m) 

E(w) 

Wq 

B 

0 

DISK/HOUR 

1 

. 0bo5 

.0160 

.2333 

.2333 

16,000 

.05'3^ 

.0007 

.0244 

.1167 

8,000 

i 

.0525 

3.45  X 10”^ 

.0018 

.0778 

5,333 

.0525 

1 . .5  X 10"^ 

.0001 

.0583 

4,000 

CASE  II: 

RECOMMENDED 

CONFIGURATION, 

1995 

PEAK 

LOAD 

(ALSO.  MINIMAL  CONFIGURATION,  1995  PEAK  LOAD) 


1 

.0808 

.0283 

.3500 

.3500 

24,000 

T 

.0542 

.0017 

.0521 

.1750 

12,000 

) 

.0526 

.0001 

.0057 

.1167 

8,000 

44 

.052  5 

6.95  X 10"^ 

.0005 

.0875 

6,000 

CASE  III; 

RECOMMENDED 

CONFIGURATION, 

1995  AVERAGE 

LOAD 

1 

.0636 

.0111 

.1750 

.1750 

12,000 

2 

.0529 

.0004 

.0141 

.087  5 

6,000 

3 

.0525 

1.48  X 10“^ 

.0008 

.0583 

4,000 

4 

.0525 

I 

O 

X 

3.43  X 10“^ 

.0438 

3,000 

. = system  utilization 

h = multiserver  queue  factor 


Wq  “ queuing  time 

E(w)  • expected  service 
t Ime 


I'.ltlier  three  or  four  Jlsks  would  be  Hullsfactory  for  this  load, 
till-  onlv  Hl>{nif  leant  difference  beliiK  that  under  peak  conditions 
somewhat  greater  redundancy  would  he  available  with  four  disks, 
since  then  two  could  fail  with  relatively  little  effect  on  re- 
sponse time.  In  addition,  four  would  provide  a greater  margin 
of  safety  in  respect  of  the  utilization,  the  estimate  for  which 
could  be  low  by  40-50%  again  with  little  effect  on  response  time. 
So  here  four  disks  will  be  assumed  for  response  time  calcula- 
t ions . 

Processing  time  is  estimated  as  in  the  case  of  input  request 
processing  for  local  and  route  briefings.  Section  4. 1.4. 3.1, 
except  that  the  number  of  instructions  to  be  executed  is  dif- 
ferent. For  example,  the  1995  peak  hour  load  calculation  Is 
20K  X 1.6/420K  + .006  ■=  .0822 

For  the  four  cases  under  cons'l  derat  ion , response  time  calcula- 
tions are  summarized  in  Tables  4-15  and  4-16. 

4. 1.4. 4. 2 Flight  Plan  Processing 

Flight  Plan  Processing  is  very  similar  to  Local  Weather  Retrieval 
Processing,  first  page,  except  that  the  flight  plan  processor 
need  not  be  considered  to  have  a preemptive  resume  queue  disci- 
pline, but  instead  can  be  modelled  simply  as  an  M/C/1  system, 
and  the  Pollaczek-Khlntchine  equations  employed.  From  the  data 
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TABLH  4-n 


MK/v;  respovsh:  times  for  processing  of  aircraft 

CONTAfT  MESSAGES  IN  ErNCTION  SHARING  CONFIGIRAT IONS 


: ii:; 

1.  AC  I’RiH.iSSlNG 
Dl^F  I/O 
.■"TA!  (SECONDS) 


HF(  O'lMENDED  CONFIGI'RATION 

1VH5  l')9S  i‘>93 

n:AK  HOCR  PEAK  HOI  R AVG . HOER 


.07R1  .0793  .0773 
• 1030  , 1050  • 1030 
.183  .184  .182 


MINIMAl. 

CONFIGt'RATrON 

1995 

PEAK  HOER 
.0793 
. 1050 
. 184 


TABLE  4-18 

MIAN  KESPO.NSE  TIMES  FOR  PROCESSING  OF 
MISCF.I.LANEOrs  MESSAC.ES  IN  FT'NCTION  SH,\RING  CONFIGERATION 


REfSAIMENDED 

CONFIGCRATIO.V 

MINIMAL 

CONFIGURATION 

r:T7' 

I9H5 

PEAK  HOCR 

1995 

PEAK  HOUR 

1995 

AVG.  HOUR 

1995 

PEAK  HOUR 

1.  MISl 

MSG. 

.0402 

.0412 

.0392 

.0412 

II  [SK 

I/O 

. HI  i 

.1313 

.Mil 

.1313 

TO  AI 

, (SECONDS) 

.171 

.173 

.170 

.173 
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in  Appendix  A,  the  first  and  second  moments  of  service  lime  may 
he  determined,  assuming;  an  distribution,  and  are  shown  In 

Table  4-17. 

ftichine  utilization  for  the  four  cases  may  be  estimated  using 
the  data  In  Appendix  A,  p = Is;  and  with  the  foregoing  data 
the  expected  queueing  time  determined.  The  results  are  sum- 
marized in  Table  4-18. 

Disk  utilization  may  be  estimated  based  on  the  data  in  Appendix 
A,  and  expected  queueing  and  waiting  times,  in  the  same  manner 
as  before.  It  is  assumed  that  flight  plan  processing  requires 
10  disk  accesses.  Again,  Cases  II  and  IV  are  the  same  for  this 
task.  The  results  are  given  in  Table  4-19. 

Clearly  two  disks  on  the  Flight  Plan  processor  will  be  adequate 
to  handle  the  load,  provide  redundancy  and  assure  a margin  of 
safety.  For  the  purpose  of  calculating  response  time,  over- 
lapped access  will  be  assumed  to  reduce  total  disk  access  time 
bv  30%, 

Response  time  may  now  be  evaluated  for  the  four  cases,  and  is 
summarized  in  Table  4-20. 
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TABI.K  4-17 


MOMK'ITS  FOR  FI.IOilT  PLAN  PROCF.SS I Nf, 


TYPE 

LsI  MOMENT 

2ncl  MOMENT 

I'-R 

(.72)(inOK)/22K  = 

.2748 

(72)inOR/262K)'^  (11/10)  = 

. 1 1 54 

VFR 

(28) (50K)/22K 

.0534 

(28)  (50K/262K)‘^  (11/10)  = 

.0112 

TOTAL 

s = 

.3282 

*T  _ 

.1266 

0 ■>  0 

.1266 

-(.3282)-  = .0189 

TABLF  4-18 

F(q)  FOR  FLIGHT  PLAN  PROCESSING 
IN  FUNCTION  SHARING  CONFIGURATION 

MINIMUM. 

RECOM>fENDFD  CONFIGURATION  CONFIGURATION 


ITEM 

14  05 

PEAK  HOUR 

1995 

PEAK  HOUR 

1995 

AVG.  HOUR 

1995 

PEAK  HOUR 

P 

.0267 

.0378 

.0189 

.0378 

E ( q ) 

.005 

.008 

.004 

.008 

p = SYSTEM 

UTILIZATION 

E(q)  - 

EXPECTED  QUEUEING  TIME 
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TABLK 
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(SYMBOLS  KXTI.AINED  ON  PACK  4-2 


MEAN  Rl-^SPONSE  TIME  FOR  FLIOHl  I’L^VN' 
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I, . 1 .5  Cost  Estimate  (Per  Hub  - Recotmnended  Conf  l^^uratlon) 

The  cost  estimate  In  Table  4-21  is  for  the  data  processing  hard- 
ware and  associated  equipment.  It  does  not  include  the  cost  for 
Specialist  or  other  consoles. 

The  design  analyzed  and  costed  here  is  intentionally  very  con- 
servative with  respect  to  component  utilization  for  the  reason 
that  large  scale  distributed  systems  are  not  yet  in  general  use 
and  this  procedure  should  ensure  adequate  reserve  capacity  for 
unanticipated  problems  and  higher  than  expected  loading.  The 
cost  could  be  trimmed  by  using  fewer  processors  or  disks,  for 
example,  but  the  relatively  small  decrease  in  cost  would  not 
Justify  the  increase  in  risk. 

The  50%  cost  Increment  for  expansion  capacity  is  an  estimate 
which,  pending  field  experience,  cannot  be  made  more  precise 
with  respect  to  specific  equipment  that  may  need  to  be  added. 
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lABI.K  4-2] 

COST  i STIM^MK  PER  HUB  FOR  RECOMMENDED 
FUNCTION  SHARING  CONFIGURATION 


Tlh/1412  PROCESSOR,  I84K  MEMORY  8 (?  $64,500 

TI6/h502  ASYNCHRONOUS  EXTENSION  BOARD  8 0 4,300 

TI6/7501  TERMINAL  CONNECTION  PANEL  8 0 775 

T16/6301  ASYNCH  CONTROLLER  8 (?  2,900 

T16/6512  CRT  8 o 2,400 

T16/3102  DISC  CONTROL  190  4,800 

TI6/4102  MliD  50M  BYTE  19  0 14,500 

T16/3201  M,\r  TAPE  CONTROL  7 0 3,800 

116/5101  M.\G  TAPE  DRIVE  7 0 7,400 

116/3301  LINE  PRINTER  CONTROLLER*  2 <3  1.800 

T16/5502  LINE  PRINTER  300  LPM*  2 (?  11,500 

T16/7103  SYSTEM  CABINET  3 0 6.800 

116/2001  DKCIM/\L  ARITHMETIC  PACKAGE  8 0 1,500 

T16/3303  CARD  READER  CONTROLLER*  1 0 1,800 

T16/5301  CARD  READER  600  CPM*  1 0 4,800 


Adding  50%  for  50%  expansion,  total  cost  Is 
$1,684,500. 


$516,000 

34.400 
6,200 

23.200 

19.200 

91 .200 
275,500 

26,600 
51,800 
3 , 600 
23,000 

20.400 
1 2 . 00^ 

1,800 

4,800 


$T, 123, 000 


* Not  included  in  system  configuration  diagram;  may  be  attached  to 
any  machine. 
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4.2  1.0 Sharing;  Configuration 

In  a load  sharing,  conf l^uratlon  there  are  several  nachines,  each 
performlnK  all  functions  of  the  Flight  Service  Station  for  a 
subset  of  the  terminals.  The  same  number  of  terminals  Is  assumed 
connected  to  each  processor.  There  may  be  off-loading  of  certain 
functions,  such  as  communications  and  weather  data  base  main- 
tenance, to  im.prove  response  time  and  reduce  duplication  of 
effort.  This  type  of  arrangement  will  be  assum.ed  here,  for  the 
reasons  explained  in  Section  4.1.3.  A discussion  of  the 
differences,  advantages,  and  disadvantages  of  the  load  sharing 
and  function  sharing  configurations  will  be  found  in  Section 
4.3.  Here,  as  in  Section  4.1,  a preliminary  design  based  on 
throughput  considerations  will  be  illustrated,  followed  by  a 
design  which,  is  m,ore  optimal  with  reference  to  response  time  and 
sensitivity  to  higher  than  anticipated  loads,  either  functional 
or  numerical.  Finally,  a queueing  analysis  will  be  performed 
on  both  designs, 

4.2.1  Assumptions 

To  analyze  the  performance  of  a split  load  distributed  processing 
configuration,  the  following  assumptions  will  be  made: 

1.  bach  machine  performs  all  functions  except  data  base 
maintenance  and  communications  with  outside  world. 

2.  Data  base  maintenance  will  be  done  as  described  for  the 
function  sharing  configuration  in  Section  4.1.3. 
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t.  TANDEM  computers  will  be  used  for  sizing'  and  costing 
purposes . 

■<.  Speed  of  T/V.NDEM  machines  assumed  to  be  that  of  NAS 
instruction  mix  (420K  IPS). 

S.  Overhead  Is  assumed  to  be  60/i  of  operational  software, 
b.  ESS  Hub  CPE  requirem.ents  are  as  in  Appendix  B,  with 
modifications  as  noted. 

7.  No  processing  will  begin  until  all  required  entries 
have  been  made. 

Ihe  effect  of  relaxing  assumption  (7)  will  be  discussed  in  Section 
A.  3. 

The  data  flow  for  the  three  major  ESS  functions  (Route  briefing, 
Local  briefing,  and  Flight  plan  filing)  is  the  same  as  that 
described  in  Section  4.1.1. 

4.2.2  Estimate  of  Number  of  .Macliines  and  Load/Machine 
The  number  of  instructions  per  second  of  raw  computing  power 
required  may  be  determined  using  the  data  in  Appendices  A and 
R.  This  is  done  in  Sections  4. 2. 2.1,  4. 2. 2. 2,  and  4. 2. 2. 3.  In 
Section  4. 2. 2. 4 the  effect  of  utilizing  the  special  method 
of  data  base  management  described  in  Section  4.1.3  is  considered. 

i-lil-i LLMlL.  Services  Throughput  Calculation 

At  this  point,  an  estimate  of  the  required  ESS  Hub  processing 
throughput,  in  Instructions  per  second,  can  be  made.  The  peak 
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hour  number  of  InHt ructions  required  for  flight  services  can  be 


calculated  as  follows: 


Route  Briefings 


Inst . /Sec  . 


6 06  route  brief s 
3600  sec 

= .188  lO*’ 


1.121  X 10 


6 Instructions 
route  brief 


Local  Briefings 
« Inst. /Sec. 


307  local  briefs 


3600  sec 
6 


-j  ^092  X 


10 


6 instructions^ 
local  brief  J 


Flight  Plans 
IFR  Inst. /Sec. 


.008  X 10 


;99  FPs 


3600  sec 


,008  X 10 


^0.100  X 


10 


6 instructions 
FP 


VFR  Inst. /Sec. 


6 Instructions 
FP 


= .002  X 10 


Aircraft  Contacts 


Inst . /Sec . 


fo-020  x 10 

3600  sec 


6 instructions 
AC  message 


.001  X 10 


Flight  Services  Instructions  Per  Second  = .207  x 10 


4. 2. 2. 2 Additional  Services  Throughput  Calculations 
In  addition  to  processing  flight  service  demands,  the  Hub  pro- 
cessor must  receive  about  1000  weather  messages  every  four  minutes 
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irfi 


i!u'  Ai-.’i'  lidi  iiii' 


; 1 . 

..fspa^e  rccorilinv, . 


rei;\ii  rer.ents ; 


;-.A  t t aiisri'.  1 ss  ion  , anil  .ilso  'io  in  i sci*  1 1 anc-ous 
This  results  In  the  foilowinn  throu^hjiut 


Ae_a_l_l.>^r  Da^i 
I nrft./ Sec.  = 


1000 

240 


r.essages\  / 
seconds  / r 


010  X 10 


,041 


10 


instruct  ions 
messages 


) 


Miscoi laneous 


,,  /16,517  messages 

ins  t. /Sec.  = j — 

3600  seconds 


= .046  X 10' 


010  X 10 


6 instructions 
messages 


lAdditional  Instructions  Per  Second  = .087  x 10 


UT.ere  16,517  = 606  + 307  + 299  + 116  + 189+  15,000  messages  per 
hour  from  flight  service,  weather  data,  and  miscellaneous 
m.essage  estimates. 


4.2.2. 3 Total  FSS  Hub  Throughput  Calculation 
."otal  FSS  Hub  Processor  throughput  is  estimated  as: 

Nur.ber  of  Instructions  Per  Second  = 

(.207  X 10^  + .087  X 10^)  (1.6)  (1.5)  = 1.18  x 10^ 

The  coefficients  in  the  equation  are  estimates  to  account  for  the 
toll  owing ; 

1.  utilization  of  the  CPI's  processing  capability; 

2.  (1.6),  60^;  operating  system  executive  overhead;  and 

3.  (1.5),  50’/  expansion  capacity. 
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» ) 


■'<  hllfct  ui  I'sing  Recommended  Method  of  DBM  (See  I’ara- 
^rapfj 

ill  tills  r.ise,  the  sum  ot  Instructions  omits  the  .041  x 10^^  Inst- 
ruct Ions  neeiii-ii  for  weather  data  base  update;  and  the  number  of 
miscellaneous  messages  per  second  Is  now  606  + 307  + 299  -•-116 
■•■  IHV  -•-  3000  4500  = 9017  and  the  total  is  thus: 

.207  X 10^  -•■  X .010  X 10^  = .232  x 10^ 

JdUU 

To  estimate  total  computln;^  power  required,  multiply  by  appro- 
priate factors  for  CPI'  utilization,  overliead,  and  expansion 
capac 1 ty : 

1 

232K  IPS  x X 1,6  X 1.5  = .93  .MIPS 

CPU  Utilization  1 , 

Overhead 1 

Expansion  Capacity  

(Expansion  Capacity  is  included  here,  but  not  in  Section  4.1, 

for  reasons  discussed  in  Section  4, 1.2.2). 


To  determine  number  of  processors  needed  (taking  into  account 
only  throughput),  first  take  number  of  instructions/sec.  and 
divide  by  instruction  speed,  then  round  to  next  highest  integer: 


.93  HIPS 
420K  IPS 


2.21,  so  3 processors  needed. 


The  peak  hour  load  per  processor  will  then  be 


.93  MIPS 
3 


310K  IPS. 
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Nt'xt  , the  luimlit'r  of  processors  required  for  rommunl  rat  i on  and 
data  b.ise  mainl enaiac  must  be  i-sllmated.  Since  the  same  tech- 
niqiu>  is  .isKumed  as  employed  for  the  function  sharing  contigura- 
tion,  the  number  of  processors  will  be  one,  operating  at  about 
1 lOK  IPS  (see  Section  4.1.2  for  details).  Finally,  one  redun- 
dant processor  will  be  required. 

To  detornine  average  terminal  ioad/processor , simply  divide  the 
number  of  terminals  by  the  number  of  processors  servicing  ter- 
minals : 

80  terminals  m _ j i / 

-r = 27  terminals/processor 

3 processors 

l.M  byte  of  main  storage  is  assumed  for  each  processor  servicing 
terminals,  IM  byte  on  the  redundant  processor,  and  384K  on  the 
back  end  processor. 

Peripheral  assignment  is  as  follows: 

Kach  processor  will  have  3 moving  head  disks  with  one  spare 
for  redundancy.  Each  machine  will  also  have  1 tape  drive, 
but  because  the  tape  drive  is  not  used  for  on-line  process- 
ing, it  is  not  duplicated. 

4.2.3  Preliminary  Configuration  and  Recommended  Configuration 
A tentative  configuration  based  on  the  foregoing  considerations 
is  shown  in  Figure  4-8.  Machine  utilization  (excluding  the  Ci’l' 
utilization  factor  and  the  expansion  factor)  is  indicated. 
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FiGUfte  4 8 

PRELIMINARY  LOAD  SHARING  CONFIGURATION 
USING  TANDEM  PROCESSORS 


Inprovor.ent  in  svsteir.  per  ! orr.inct'  ami  iail-soir  c.ipah  i I 1 1 i es  r.iv 


be  realized  bv  addition 
Such  a coni' i^;urat  ion  Is 
per  processor  is: 

. d 1 r pc 

= ^ViK 


ot  one  more  terminal 
shown  In  KiKurc  4-'). 


irs 


handling  processor. 
The  peak  hour  load 


The  number  of 


terminals  per  processor  will 


20. 


The  expected  perform.ance  of  both  of  these  conf  ij^urat  ions  is 
analyzed  in  Section  4.2.4. 


.4.2.4  tjueueing  Considerations  For  a Load  Sharin g FSS  Configura- 
tion 

4. 2. 4.1  (leneral 

In  a load  sharing  distribution  processing  configuration,  each 
machine  performs  all  functions  of  the  FSS  except  processing  of 
incoming  weather  data,  which  is  assumed  to  be  handled  by  a separate 
machine.  Each  of  the  terminal  handling  processors  is  physically 
connected  to  a number  of  terminals,  and  manages  all  of  their 
requests.  Since  the  tasks  vary  considerably  in  importance  and 
length,  as  discussed  in  Section  4.1.4,  each  processor  will  utilize 
an  yjcjl  Preemptive-resume  queueing  scheme.  Here  12  levels  of 
priority  are  assumed,  as  shown  in  Figure  4-10. 

4.  ■ 2 . 4 . 2 Analysis  of  System  I'nder  Load 
The  following  cases  will  be  analyzed: 

1.  Case  I - Peak  hour,  1985,  four  terminal  handling  processors. 

2.  Case  II  - Peak  hour,  1995,  four  terminal  handling  pro- 


cessors . 
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CI’U 


I 


(1)  Processor  status  messages 

(2)  Data  base  update 

(3)  Input  from  terminals  - all  categories 

(4)  Output  to  terminals  - weather  data,  pages 

(5)  Output  to  terminals  - other  categories 

(6)  I/O  ready  list,  disk  processing,  weather  retrieval  - 
first  page 

(7)  Route  processing 

(8)  Flight  Plan  Processing 

(9)  Aircraft  contact  processing 

(10)  uogging  and  Miscellaneous  messages 

(11)  I/O  ready  list,  rest  of  route  brief 

(12)  I/O  ready  list,  rest  of  local  brief 


FIGURE  4 10 

CATEGORIES  IN  LOAD  SHARING  CONFIGURATION 
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i.  Case  III  - Avera^ic  hour,  199i,  lour  terminal  handling. 


processors . 

4.  Case  IV  - Peak  hour,  1995,  three  terminal  handling,  pro- 
cessors. 

For  each  of  these  cases,  the  load/processor/hour  Is  given  in 
Table  4-2.’,  based  on  Appendix  A. 

4. 2.4. 2.1  CPU  Analysis 

In  order  to  determine  the  queueing  and  waiting  times  for  the  12 
categories  In  each  of  the  four  cases,  the  first  and  second  moments 
of  service  time  distribution  must  be  known.  These  are  tabulated 
in  Table  4-2  i with  the  12  Individual  categories  given  In  the  left 
column,  together  with  their  respective  first  and  second  moments 

and  and  the  corresponding  value  of  X (polsson  arrival 

rate)  for  each  of  the  four  cases. 

Waiting  times  are  determined  by  using  the  formulae  for  a preem.ptlve- 
resume  queueing  model.  The  results  of  these  calculations  are 
summ.arized  in  Table  4-24  for  the  12  categories  in  each  of  the 
four  cases.  Also  given  is  the  service  time,  to  facilitiate  direct 
comparison  with  the  estimated  mean  waiting  time.  All  numbers 
are  given  to  three  significant  figures. 

4. 2. 4. 2. 2 Disk  Analysis 

Disk  queueing  must  now  be  analyzed.  The  same  assumptions  as  in 
Section  4. 1.4. 2. 5 are  made  with  respect  to  the  disks,  and  again 
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TABl.F  U-n 

PROCESSOR  LOAD  FOR  DIFFERENT  DEMAND  CONDITIONS 


ROUTE 

BRIEFING 

LOCAL 

BRIEFING 

FLIGHT 

PLAN 

AIRCRAFT 

CONTACT 

Case 

I 

104 

51 

73 

36 

Case 

II 

152 

77 

104 

42 

Case 

III 

76 

38 

52 

23 

Case 

IV 

202 

102 

138 

63 
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^4-2'} 

MOMKNTS  A.ND  INTERARRI VAL  RATES  (^)  FOR 
DATA  PROCESSING  CATEGORIES 


^ for  Case 


1 

I 

II 

III 

IV 

f 

1 

1 1.  Processor  status  messages 

1 ' 75  instr.  each 

Service  time  assum.ed 
' constant 

' U * .0003  sec 

I i “ H X 10  sec 

6/sec 

6/ sec 

6/sec 

5/ sec 

! 

i 

! 2.  Oata  base  update‘ 

90/hr  - 

90/hr  - 

90/hr  = 

90/hr  = 1 

' 500  instr.  each 

1 E.^  service  tine  dlstr. 

1 

: (1) 

.i2  “=  .0019  sec 

(2)  -6  2 

1 x2  “4.9x10  sec 

.C25/sec 

.025/ sec 

.025/ sec 

.025/sec  j 

1 3.  Input  iron  terminals 

all  categories 

7 lOK  instr. 

E^  service  tine  dlstr. 

a3^^^  - .0382  sec. 
a3  **  .0019  sec 

7 5 3 / h r “ 
.2092/sec 

1129/hr  “ 
.3137/sec 

564/hr  “ 
.1568/sec 

1506/hr“ 

.4182/sec 

4.  Output  to  terminals 

Weather  data,  pages“ 

Flight  plans,  pages*** 

^ 5K  Instr. 

Ejj^  service  time  dlstr. 

a4^1>  . .019 
a4^^^  • .004  sec^ 

1656/hr 
. 4600/sec 

2425/hr  - 
. 6737/sec 

1214/hr  - 
. 3372/sec 

3222/hr  • 
.8950/sec 

*Sce  note  on  this  Item  In  Section  4. 1.4. 2. 4. 

‘•Assumes  weighted  average  of  13.75  pages  per  route  brief,  3 pages  per 
local  brief. 

‘“Assumes  one  page  per  flight  plan. 
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lAHI.r  4-.’  i 
(CONTD) 

' for  Case 


1 

I 

n 

III 

IV 

i S.  Output  to  terminals,  other 

■iOh/hr  ' 

758/lir  = 

i/9/hr  - 

101  1/hr  = 

1 Categories 

. 1405/ sec 

.2107/sec 

. 1053/soc 

.2809 /sec 

IK  instruct  ions 

1 , service  time  dlstri. 

: (O 

1 » .onjH 

i .5 

1,^  - 2 X 10 

1 

i 

1 

i I- ■ I/.'  readv  list  f,  pro- 

154/hr  = 

228/hr  = 

114/hr  = 

304/hr  = 

cesslnn  First  page 

. 0428/sec 

.06 3 3/ sec 

.0317/sec 

, 0844 /sec 

; f route  i local  briefs) 

1 ■ IbK  instructions 

! K service  tine  distr. 

1 

“ .Obll  sec 
n 

(2)  2 
t * .0050  sec 

h 

i 

1 

7.  Flight  Plan  Processing 

73/hr  “ 

104/hr  = 

52/hr  = 

138/hr  = 

HbK  instructions* 

. 0203/ sec 

.0289/sec 

.0144^  sec 

.0383/sec 

4*'  - .128 

1 

1 

(2) 

uj  ^ - .1558 

1 

1 8.  Alrcralt  Contact  Processing 

3b/br  = 

47/hr  = 

2 3 /hr  = 

63 /hr  - 

20F  instructions 

. 0100/sec 

.0131/sec 

. 0064 / sec 

.017S/sec 

1 , service  time  distr. 

• .07b  1 sec 
b 

'in  • .00/8  sec 



*See  Section  4, 1.4. 4. 2 of  previous  analysis  for  moments  and  distributions. 
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TABI.F.  4-2  3 
(CONTD) 


X for  Case 


I 

11 

111 

IV 

’ (<.  I.oK>;in>>  and  Miscellaneous 

1250/hr  = 

1875/lir  * 

938/lir  * 

2500/hr  = 

i raessaKes  3 9500  instructions 

.3472/ sec 

. 5208/sec 

. 2606/sec 

.6944 /sec 

1 service  time  distr. 

1 ' .0363  sec 

1(2)  2 
- .0020  sec 

1 

10.  Route  Processing 

in4/hr  - 

152/hr  - 

76/hr  = 

202/hr  = 

434K  Instructions 

. 0289/sec 

. 0422/ sec 

. 0211/sec 

. 0561/ sec 

F.  service  t lir.e  distr. 

1 i f) 

= 1.66  sec 

* 3.02  sec^ 

X U 

11.  I/O  ready  list  - rest  of 

104/hr  ‘ 

152/hr  - 

76/hr  • 

202/hr  » 

route  brief 

. 0289/ sec 

. 0422/sec 

.0211/sec 

. 0561/sec 

> 671K  Instructions 

service  tlrr.e  distr. 

ij,  “ 2.56  sec 

- 9.(39  sec^ 

12.  1/0  ready  list  - rest 

51/hr  - 

77/hr  - 

38/hr  “ 

102/hr  - 

ot  local  brief 

.0142/ sec 

.0214/ sec 

.0106/sec 

.0283/sec 

• 76K  instructions 

E.J  service  time  distr. 

• .290  sec 

- .112  sec^ 

3 


I 

TABLK 

CPU  WAiTiNC.  Tira:s  for  load  sharinc  configuration 


— 

gatfoopy 

SFRVICE 

TIMF 

CASF  I 

CASF  II 

CASF  III 

CASF  IV 

Status  Messages 

.000300 

.000300 

.000300 

.000300 

.000300 

1 

.'iita  h.ise  I'pdace 

.00190 

.00190 

.00190 

.00190 

.00190 

) . 

Terr.inal  input 

.0382 

.0385 

.0  '86 

.0  389 

.038/ 

■utpiic,  '.v'eati.er 
Data,  FI’ ' s 

.0190 

.020  3 

.0210 

.0200 

.0216 

Output,  Other 
Cattvor  les 

.003B0 

.0050A 

.00569 

O 

O 

.00629 

; 8. 

Kirvt  Pro- 

cessing; 

.0811 

.06  36 

.064  7 

.0629 

. 0660 

7 , 

FlinhC  i'lan 
i’rocess  in>’ 

. 328 

. 340 

. 396 

. 3 3 7 1 

. 352 

1 s. 

1 

Aircraft  Contact 
Processing 

.0763 

.0837 

.0872 

.0816 

.0910 

9. 

Niscel laneous 
■Ness.ixe  Pro- 
cess Iny; 

.036'J 

. OA  30 

.0462 

.0911 

.0999 

i 10. 

Route  Processing: 

1.66 

1 .79 

(X 

1.75 

1.93 

1 

11. 

Rest  ot  Route 

Briel  ProcessinK 

2.56 

3.06 

3.  37 

2.91 

3.75 

Rest  ot  Local 
brief  Processing 

.290 

.622 

.868 

.511 

1.23 

a rr.ul C 1 -server  <|ueuelnK  niodel  Is  employed.  The  number  of  disks 
acccsses/hour  for  tlie  four  ca.ses  Is  itemized  by  catenory  In 
Table  4-J5. 

For  each  of  the  four  cases,  the  expected  queueing  and  waiting 
times  are  deCerm.lned,  assuming  one  to  four  disks  per  machine 
(see  Table  4-26) . 

In  all  cases  four  disks  per  processor  seems  to  be  the  best  choice 
both  on  account  of  the  redundancy  it  provides  and  the  margin  of 
safety  with  respect  to  utilization. 

4. 2.4. 2. 3 Response  Time  Calculation 

Using  the  foregoing  data,  response  time  for  seven  categories  of 
interest  may  be  determined.  In  all  cases  except  the  route  pro- 
cessor It  is  assumed  that  overlapped  disk  accesses  will  reduce 
disk  access  time  by  a factor  of  two.  The  results  are  summarized 
in  Table  4-27 . 

4. 2. 4. 3 Comparison  of  The  Response  Times  of  Function  Sharing 
And  Load  Sharing  Configurations 

In  general,  the  performance  of  the  two  recommended  configurations 
is  very  similar  and  is  summarized  for  the  1995  peak  hour  load  in 
Table  4-28.  Route  brief  processing  time,  for  example,  is  within 
IX  for  first  page  output.  The  only  items  showing  any  relatively 
large  deviation  are  those  that  Involve  interprocessor  transfers 
on  the  function  sharing  configuration,  and  are  of  short  rv^.n  times. 
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F;(W)  = MEAN  SERXTCF:  Tint:  B = PROBABILITY  AI.I.  SERV’ERS  BISY 

W(q)  = MEAN  QL^EUEING  TIME;  p = SYSTEM  UTILIZATION 
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Htn  overhead  causi-.s  the  t unction  stiarinK  con!  i^urat  ion  to  be 
lOO-dOf)  a.sec . r.  lower  io.g..  local  brie!  1 nr,  fllr.ht  plan  lllinr). 
"hfHf  d I r I erenceh  , however,  cannot  he  re^iirded  as  slKnlflcant 
due  to  the  short  response  titnes  Involved  (less  tlian  one  second). 

For  both  conf inurat Ions , the  fact  that  the  Case  IV  numbers  (minimal 
h.ardware)  shows  a relatively  small  degree  of  response  time  de- 
gration  for  nearly  all  functions  Indicates  that  the  systems  have 
a comfortable  margin  of  safety  designed  in  with  respect  to  per- 
formance . 

For  comparison  purposes,  response  time  estimates  for  two  large 
main  1 rame  configurations  are  presented  in  Appendix  C,  and  for 
one  oi  the  two  is  included  in  Table  4-28. 

4.2.5  Cost  Estimate  (Per  Hub,  Recoironencied  Configuration  of  4 
Terminal  Handling  Processors) 

The  cost  estim.ate  in  Table  4-29  Is  for  the  data  processing  hard- 
ware and  associated  equipment,  and  does  not  include  the  cost  of 
consoles  for  use  by  the  .Specialists  or  supervisory  personnel. 
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T16/5301  Card  Reader  600  CI’M*  1 0 4,800  = 4,800 


• . . f t'or.pa ; .-.un  .m^!  I v.i  1 ua  t 1 on  o i l.o.u!  Sli.i  i i ii^;  .iiul  I uiii  t i mi 

S r ijT^  JK' s 

A'.  t!i('  (jucufliu-  aiialv.es  ot  Sections  . i . and  demonstrate, 

there  is  relativ'ely  little  difference  between  the  function  sharlnK 
and  load  sharlny,  distributed  processing  configurations  with 
respect  to  performance.  Moreover,  both  arc  fail-safe,  so  that 
a loss  of  one  element  will  have  no  effect.  The  primary  differences 
between  the  configurations  will  be  the  difference  in  development 
retjulred  for  each,  and  the  difference  In  their  fail-soft  perfor- 
mance . 

The  load-sharing  configuration  is  the  closest  to  what  already 
exists  in  operational  form,  and  involves  the  least  risk  from,  the 
standpoint  of  being  the  least  "distributed"  of  the  two  configura- 
tions. its  capacity  (with  respect  to  number  of  terminals  handled 
per  Hub)  can  easily  be  expanded  by  addition  of  complete  subsystems 
of  terminal  handling  processors  and  peripherals.  It  is  also 
easily  adapted  to  Hubs  of  different  loads  by  changes  in  the  number 
of  terminal  handling  processors.  If  the  functional  capacity  of 
the  machine  should  ever  become  overtaxed,  additional  machines 
could  be  added  and  the  load  (number  of  terminals)  on  each  reduced. 
In  tail-soft  mode,  this  type  of  system  will  degrade  by  loss  of 
some  number  of  terminals. 

The  1 unction  sharing  configuration  is  the  more  elegant  of  the 
two,  and  more  in  the  general  direction  that  distributed  processing 
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.i;)|uMi  to  1)1'  In  .nKlll  ioii,  its  software  woulil 


o I ms  I'.s  1 t V have  to  1h'  ihihIu  1 a i . atul  t h I i.  won  1 .1  I ai  I I llalo 
s [ roc  1 u ri'ii  pr. ',;r.'iminl  II,’,.  .Additional  Itjucllons  (o.);.,  voire  les- 
ponse  svstems)  I’ouKi  etislly  be  aecommodaC eii  by  addition  of  .i 
new  n.nhine  dedicated  to  tlte  ta.sk.  Additional  nuji’hines  rould 
e.isllv  be  added  .is  route  proee.ssors  or  terir.inal  interface  machines, 
for  example,  it  these  prove  to  be  system  bottlenecks.  Allowin.it 
.idditionai  machines  lor  an  exp.insion  capacity  equivalent  to  that 
of  the  load  shariiiM  con  f i p,ura  t ion , the  function  sharing;  configura- 
t iiin  turn.s  out  to  be  somewhat  more  expensive  hardware-wise  per 
Hub . 

4 . J . I Effect  on  Ke.sponse  Time  of  KeJaxing  Assumption  (7  J 
Assumption  (7),  Sections  4.1.1  and  4.2.1,  forbade  the  data  pro- 
cessing system  from  starting  to  work  on  a job  until  all  entries 
have  been  completed.  In  some  cases,  notably  for  route  briefings, 
it  may  be  of  some  advantage  to  begin  processing  before  all  entries 
are  completed.  In  particular,  as  soon  as  a route,  e.g.,  LAX-IAD, 
is  detected,  the  route  processor  could  be  initiated.  Although 
it  is  difficult  to  estimate  precisely  how  much  impact  this  would 
have  on  overall  response  times,  the  following  breakdown  appears 
reasonable:  (1)  In  25Z  of  cases,  the  Specialist  either  enters 
the  route  last,  or  enters  no  other  Information  and  simply  requests 
weather  between  two  points;  (2)  In  75%  of  cases,  one  or  more 
additional  lines  of  information  will  be  typed  in.  Since  this 
will  generally  take  at  least  two  seconds,  in  nearly  all  cases 
the  route  processor  will  have  finished  its  task,  and  so  its  time 
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will  drop  out  of  the  overall  response  time  tigure.  iicnco , mean 


response  times  for  route  briefings  (first  page)  will  drop  by 
about  1.5  secon<is,  to  about  1.2-1. 3 secon<is.  But  of  course  this 
me.in  tigure  is  not  representative  of  actual  response  time,  whicli 
will  either  remain  at  about  2.7  seconds  or  drop  to  about  .4 
seconds . 

There  appears  to  be  no  engineering  reason  why  processing  could 
not  be  done  in  this  manner,  as  in  fact  it  currently  is  In  the 
AWA.V.S  system. 
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bk:k.fin(.s  by  vkndors 


DurlPK  tlu-  loursf  ot  tin-  MITKK/KAA  1)1  st  r I i)ul  i-il  P roc'usH  1 ng  hIucIv 
ot  March  19/7  led  hy  AR;)-4A0,  several  vendors  ii,;ivc  briefings  on 
their  products,  with  specific  reference  to  distributed  processing: 

1.  Raytheon  Corporation 

2.  Digital  hejuipment  Corporation 

3.  Data  Ceneral  Corporation 

4.  Interdata  Corporation 

5.  Tandem  Corporation 

6.  Texas  Instruments  Corporation 

7.  Burroughs  Corporation 

Several  things  became  apparent  during  the  course  of  these 
briefings:  (a)  onlv  one  manufacturer  has  addressed  the  problem 
of  fail-safe  head-on,  i.e.,  designed  and  built  a system  from  the 
ground  up,  integrating  both  hardware  and  software  so  as  to  cover 
all  potential  single  points  of  failure,  provide  special  dual 
power  supplies,  etc.,  (b)  other  manufacturers  have  assembled  the 
hardware  for  multiprocessing  systems,  but  non  offers  fail-safe 
capabilities  or  features  off-the-shelf,  nor  did  any  point  to 
distributed  processing  i nstal lat ions  we  might  visit.  Only  the 
one  company  offered  to  release  the  names  of  all  its  customers  and 
invited  the  study  team  to  visit  whomever  it  chose  to  verify  its 
claims,  (c)  in  general,  the  minicomputer  manufacturers  are  still 
geared  to  dealing  with  the  customers  who  buy  minicomputers 


5-1 


because  they  are  cheap,  and  who  wish  to  squeeze  all  available 
computing;  power  out  of  them;  this  of  course  Is  Incompatible  with 
Kood  response  time  in  systems  with  random  Inputs  (and  the  design 
goals  of  the  KSS  program  generally),  but  apparently  that  con- 
sideration is  of  little  or  no  concern  to  most  of  these  customers 
F.ven  some  of  the  distributed  processing  configurations  appeared 
to  be  designed  with  the  same  goal  of  maximizing  throughput  in 
mind.  Clearly  for  most  minicomputer  manufacturers,  the  hardware 
associated  with  fail-safe  operation  would,  for  the  average  cus- 
tomer, be  an  uneconomical  and  uncompetitive  extravagence . 
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APPENDIX  A 


DEM^vND  ESTIMATES  FOR  1985,  1995* 

A.l  1985  - Cleveland  Hub  (Worst  Case;  Peak  Hour) 

A.  1.1  Peak  Hour  Statistics 

1.  Pilot  Briefs  - 616 

2.  Flight  Plans  - 292 

3.  Aircraft  Contacts  - 145 

A. 1.2  Calculations  of  IFR  and  VFR  Flight  Plana 

72%  of  flight  plans  are  IFR  = (293) (.72)  = 211 
VFR  = Total  - IFR  = 293  - 211  = 82 

A. 1.3  Calculation  of  Route  Oriented  and  Local  Briefings 

All  IFR  briefings  are  route  oriented  = 211 

50%  of  VFR  briefings  are  route  oriented  = (. 5) (616-211)  = 203 

Total  route  oriented  briefs  414 
Total  local  brii fs  = Total  briefs  - route  briefs  = 616-414  = 202 

A. 2 1995  - Cleveland  Hub  (Worst  Case;  Peak  Hour) 

A. 2.1  Peak  Hour  Statistics 

a.  Pilot  Briefs  - 913 

b.  Flight  Plans  - 415 

c.  Aircraft  Contacts  - 189 

• • i on  Reference  5,  Appendix  C. 
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A.  2.2 


Calculation  of  IFR  and  VFR  Flight  Plans 
117  of  riiKht  plans  are  IFR  = (415)(.72)  = 299 
VFK  = I’ota]  - IKK  = 415  - 299  “ 11 A 

A. 2. 3 Calculations  of  Route  Oriented  and  Local  Briefings 

All  IFR  briefings  are  route  oriented  = 299 

50%  of  VFR  briefings  are  route  oriented  = (. 5) (913-299)  = 307 

Total  route  oriented  briefs  606 
Total  local  briefs  = Total  briefs  - route  briefs  = 

913  - 606  = 307 

A. 3 Average  Hour  Demand 

Based  on  the  tables  and  graphs  in  MITRE  MTR-6607,  Vol.  II,  FSS 
Configuration  Analysis  Study,  average  hour  demand  is  very  close  to 
half  of  the  peak  hour  demand. 

A. 4 Demand  Summary 

Below  in  Table  A-1  is  a summary  of  peak  and  average  hour  demand  for 
1985  and  1995. 

A. 5 Specialist/PUAT  Split 

For  1995,  the  Route  Briefings  are  assumed  to  be  split  as  follows: 

25%  Specialist 
75%  Pilot  at  DUAT 
This  yields 

(.25) (606)  = 152  Specialist  Briefings 
(.75) (606)  = 459  Pilot  self-briefings 
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TABLE  A-1 


DEMAND  SUMMARY  FOR  1985,  1995 

1985  1995 


AVERAGE 

PEAK 

AVERAGE 

PEAK 

IFR  FLIGHT  PLANS 

106 

211 

150 

299 

VFR  FLIGHT  PLANS 

41 

82 

58 

116 

ROUTE  ORIENTED  BRIEFS 

207 

414 

303 

606 

LOCAL  BRIEFS 

101 

202 

154 

307 

AIRCRAFT  CONTACTS 

73 

145 

95 

189 

MISCELLANEOUS  MESSAGES* 

1000 

2000 

1500 

3000 

LOGGING  MESSAGES 

1528 

3054 

2260 

4517 

* ASSITIED  TO  BE  APPROXIMATELY  DOUBLE  THE  SUM  OF  THE  OTHER  MESSAGES. 
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A. 6 Miscellaneous  Messages,  Logging  Messages 

Miscellaneous  messages  and  logging  messages  are  assumed  to  be  as 
shown  in  Table  A-1. 
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ESTIMATE  OF  IN’STRL'CTIONS  EXECUTED  A\D  DISK  ACCESSES  REQUIRED  FOR  FSS 

SYSTEM  FUNCTIONS 


B. 1 Summary  of  Data  Used  In  Report 

Table  B-1  sumiriari zes  the  instructions  required  for  a typical  low  al- 
titude route  oriented  briefing.  Table  B-2  does  the  same  for  a 
typical  local  briefing.  The  data  in  these  tables  are  based  on 
information  presented  in  Section  B.2.  Table  B-3  summarizes  the 
instructions  required  for  other  classes  of  FSS  activity. 

B.2  Origin  of  Data  Used  in  Estimates  of  Instructions  for  FSS 
Functions  in  Section  B.l  , 

In  this  section,  the  data  on -which  the  figures  in  Section  B.l  are  based 
are  given,  including  instructions  for  file  retrieval  by  weather  type 
(Table  B-4),  average  number  of  items  retrieved  by  type  (Table  B-5) , 
winds  and  temperatures  aloft  calculation  data  (Table  B-6)  , data  base 
characteristics  and  disk,  access  counts  by  weather  type  (Section  2.1), 
and  instructions  executed  during  route  processing  (Section  2.2).  For 
some  operations,  however,  hard  data  are  not  available,  and  estimates 
had  to  made  (e.g.,  line  and  area  filtering). 

B.2.1  MITRE  Exi^er imental  PSBT  System  - Converted  Data  Base 
Characteristics 

B.2.1. I SA 

A.  File  Organization  - Sets  of  three  logical  records  arranged 
alphabetically  to  correspond  to  PSBCMI  array  SALOC.  Each  set  of 
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TABLK  B-3 


INSTRIKTION'S  RKQUIREO  FOR  OTHER  CLASSES  OF  ESS  ACTIVITY 

ELlCtlT  i’i>/\NS 

IFR  FLIGHT  PLANS  (SOME  FORMAT  CHECKING) 

VFR  FLIGHT  PLANS 

AIRCRAFT  CONTACTS 

AIRCRAFT  CONTACT  MESSAGE 

WEATHER  DATA 

FPDATE  ONT;  weather  REPORT  = 0.01  x 10^ 


= 0.02  X 10 


= 0.10  X 10^ 
= 0.05  X 10^ 


MISCELLANEOUS 


REXOROING  ONE  MESSAGE 
AMENDMENT  MESSAGES 
DEPAPTl'RE  MESSAGES 
PROGRESS  REPORT  MESSAGES 
EXIGHT  PIvVN  READOUTS 
LIST  DISPLAYS 
AFOS  GRAJ’HICS  LTDATE 

WT-:ATHER  RADAR  DIAL  UP  AND  DISPLAY  UPDATE 

SA/NO  ENTRY 

PILOT  REPORT  ENTRY 

TWEB / PATWAS  P REP ARAT I ON 

INTERFACILII-Y  TRANSMISSION 

AV-AWOS  PROCESSING 

SUPERVISORY  INPUTS 


0.01  X 10^ 
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A 


TAlil.l  It-A 


WINDS  AND  TEMI’ERATURES  ALOET 
TIMING  DATA 
PDF  11/70,  RSX  IID 

SINGLE  ROLTE  BOS/BAL 

CONSTANT  TIME  (SEC)  POINT  TIME  (SEC)  NUMBER  OF  POINTS 


0.0140 

0. 1484 

8 

0.0153 

0.1597 

8 

0.0162 

0.1653 

8 

0.0160 

0.1654 

8 

0.0160 

0.0207 

1 

0.0155 

0.0200 

1 

0.0173 

0.0195 

1 

0.0154 

0.0198 

1 

TOTAL  0.1257 

0. 7188 

36 

AVERAGE  0.0157 

0.0200 

ASSL'Mi:  MACHINE  = . 25  x lO^INST./SEC 
II  INSTRUCTIONS  = (0.25  x 10^)  (0.0157  + 0. 02/POINT) 
= (.004  X 10^  + .005/POINT) 
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three  accommodates  one  SA  and  allows  space  for  two  potential 


SPs.  Flags  in  the  SA  record  for  a LOCID  indicate  the  presence 
of  SPs,  thus  no  attempt  will  be  made  to  read  SPs  if  none  are 
available. 

B.  Access  Technique  - Binary  search  of  SALOC  yields  ordinal  of 
SA  logical  record. 

Logic  Disk  Address  = 3 * Ordinal  - 2 

C.  Overhead  accesses  - None 

D.  Access  for  logical  read  - 1 of  256  bytes  for  SA 

E.  Overhead  instruction  count  - 0 

F.  Access  instruction  count  - 2000 

B . 2 . 1 . 2 L'A 

A.  File  Organization  - Index  record  at  file  head,  logical 
records  follow. 

B.  Access  technique  - Read  index  into  main  memory  and  examine 
for  LOCID  match,  if  match,  retrieve  UA  using  logical  disk  ad- 
dress from  index. 

C.  Overhead  accesses  - 1 of  3840  bytes  to  read  index. 

D.  Access  for  logical  record  - 1 of  256  bytes  for  L'A. 
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E.  Overhead  instruction  count  - 10000 


F.  Access  Instruction  count  - 5000 

B.2.1.3  FA 

A.  File  Organization  - Records  organized  according  to  geo- 
graphic region. 

B.  Access  technique  - Binary  search  of  SALOC.  If  match  on 
LOCID,  byte  3 of  SALOC  entry  contains  geographic  region  code 
for  LOCID.  Logical  Disk  Address  = geographic  region  code. 

C.  Overhead  Accesses  - None 

D.  Access  for  logical  record  - 1 of  4000  bytes  for  FA. 

E.  Overhead  instruction  count  - 0 

F.  Access  instruction  count  - 2500 

B . 2 . 1 . 4 FT 

A.  File  Organization  - Logical  records  arranged  alphabetically 
to  correspond  to  PSBCMI  array  FTLOC. 

B.  Access  Technique  - Binary  search  of  FTLOC  yields  FTLOC 
ordinal  which  is  the  requried  logical  disk  address. 

C.  Overhead  Accesses  - None. 

D.  Access  for  Logical  record  - 1 of  1024  bytes  for  FT. 
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E.  Overhead  Insiructlon  count  - 0 


K.  Access  Instruction  count  - 2500 

B.2.1.S  WA/WS 

A.  File  Organization  - Doubly  subscripted  index  table  at  head 
of  file  allows  for  ten  WA/WS  to  be  retrieved  for  each  of  the 
nine  geographic  regions. 

B.  Access  technique  - Read  index  into  main  memory,  perform 
binary  search  of  SALOC,  extract  geographic  region,  retrieve 
all  available  reports  for  geographic  region  - logical  disk 
addresses  available  from  index. 

C.  Overhead  accesses  1 of  540  bytes  for  WA 

1 of  540  bytes  for  WS 

D.  Access  for  logical  record  - 1 of  800  bytes  for  WA 

1 of  800  bytes  for  WS 

E.  Overhead  instruction  count  WA  - 5000 

WS  - 5000 

F.  Access  instruction  count  WA  - 5000 

Ws  - 5000 


B . 2 . 1 . 6 WW 

A.  Index  at  head  of  file 
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B.  Accesn  t crhniijuv  - Read  index  into  main  memory,  retrieve 
all  reports,  logical  disk  addresses  available  in  Index. 

f.  Overhead  Accesses  - 1 of  300  bytes 

D.  Access  for  logical  record  - 1 of  4096  bytes 

E.  Overhead  instruction  count  - 10000 

F.  Access  instruction  count  - 10000 


B ■ 2 . 1 . 7 NO 

A.  File  Organization  - Thirteen  indexes  for  report  collectives 
distributed  every  130  logical  records  throughout  file. 


B.  Access  technique  - Read  thlrtee  index  records  into  main 
memory,  consolidate  index,  removing  null  entries,  search  se^ 
quentlally  for  match  on  LOCID. 


C.  Overhead  Accesses  - 13  of  320  bytes 


D.  Access  for  logical  record  - 1 of  256  bytes 

E.  Overhead  Instruction  count  - 45000 

F.  Access  Instruction  count  - 8000 


B.2.1.8  TR 

A.  File  Organization  - Indexed  directly  from  TWEB  Route  Number 
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B.  Access  Technic, ue  - Convert  TWKB  route  iiunber  to  Integer 
which  is  logical  disk  address. 

C.  Overhead  Accesses  - None 

n.  Access  for  logical  record  - 1 of  800  bytes  for  TR 
K.  Overhead  instruction  count  - 0 

F.  Access  instruction  count  - 2500 

B.  2. 1.9  TS 

A.  File  0rgani2ati()n  - Data  indexed  by  table  internal  to 
MEPTS,  PFA 

B.  Access  technique  - Scan  local  table  for  LOCID  match,  table 
ordinal  on  LOCID  match  provide  logical  disk  address 

C.  Overhead  accesses  - None 

D.  Access  for  logical  record  - 1 of  800  bytes  for  TS 

E.  Overhead  instruction  count  - 0 

F.  Access  instruction  count  - 2000 
B.2.2  Route  Processing  Instructions  Executed 

Data  for  Table  B-7  were  gathered  in  a series  of  runs  on  NITRE's  ex- 
perimental route  processor  programs  in  a sterile  environment  on  a 
PDP  11/70.  No  other  users  were  permitted  on  the  system.  For 
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f.ich  roiitf  shi)wn,  the  data  in  Columns  A,  B,  C,  D,  and  F were  supplied 
hv  the  computer  throu^;h  timing  routines  in  the  route  processor  in- 
serted for  that  purjiose.  The  other  Columns  were  computed  as  shown 
from  tlu'  computer-supp 1 led  information.  The  purpose  of  this  study 
w.is  threefold:  to  determine  (1)  system  overhead  (shown  as  percent 
of  total  route  processor  time.  Column  H) , (2)  number  of  instructions 
required  for  route  processing  (shown  in  Column  J) , and  (3)  any  sig- 
nificant relationships  between  distance  and  number  of  instructions. 
The  re  l.it  ionsii  ip  between  data  in  Columns  J and  K turned  out  to  be 
the  most  important;  a regression  analysis  of  the  numbers  in  these 
columns  led  to  the  following  equation: 
i « 348K  + IHOd 

where  i • number  of  instructions  required  for  route  processing 
(Column  I)  and  d ” route  distance  in  nautical  miles  (Column  K) . This 
line  and  the  data  from  Columns  J and  K are  plotted  in  Figure  B-1. 

The  tit  is  very  good,  as  demonstrated  by  the  high  value  of  the 
correlation  coefficient  from  the  regression  analysis:  0.98. 

The  graph  mav  be  used  for  Hub  sizing  merely  by  determining  the 
average  length  of  a route  of  flight,  and  reading  the  corresponding 
number  of  Instructions  required  directly. 

• 

Based  on  discussions  with  FSS  Specialists  at  the  Leesburg  Center, 
the  following  data  for  the  length  of  route  oriented  briefings  appear 
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Lo  lu'  Conservative  cstlniates; 


I)  I STANTi; 

KA.NOl 

: (nm) 

PERCENT  OK  hKIEEINGS 

100- 

500 

85 

■1500 

15 

Assuming  a uniform  distribution  of  lengths  within  each  range,  and  a 
maximum  length  of  2500  nm,  we  can  compute  the  average  route  length 
as  follows: 


E(d) 


= (^22^^  100 


.85  + 


(2500-500 

I 2 


+ 500  X .15  = A80 


This  figure  does  not  reflect  any  briefings  for  routes  less  than  100 
miles,  since  the  Specialist  said  these  were  virtually  never  route- 
oriented.  This  figure,  substituted  into  the  above  equation,  leads 
to  a mean  number  of  instructions  of 
348K  + (180) (420)  = 424K 
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Ari'KNDIX  C 


RKSPONSi:  TIMK  ESTI  MATHS  FOH  l.AKCK  MAINFK/\MK  COMPUTER  SYSTEMS 

To  facilitate  evaluation  of  the  response  times  for  minicomputer 
systems  derived  in  Section  A,  similar  calculations  are  made  in  this 
Appendix  for  two  sampli’  lar>;e-scale  computer  systems,  assuming  1995 
peak  load.  Such  a system  would  of  necessity  be  of  the  load  sharing 
type,  with  either  one  machine  handling  the  entire  load,  and  one  as 
a 'hot  standby,'  or  two  machines  sharing  the  load  equally,  but  either 
capable  of  taking  over  completely  in  the  event  of  a failure  in  the 
other.  Tlie  procedure  followed  in  Section  4.2  for  determining  ex- 
pected waiting  time  and  expected  response  times  is  also  employed 
here,  with  the  exception  that  only  one  case  is  analyzed,  viz.  the 
1995  peak  load.  The  same  disk  access  times  are  also  assumed. 

Table  C-1  summarizes  expected  waiting  times  and  related  queueing 
parameters  for  a system  with  raw  computing  speed  of  2.4  MIPS,  which 
(applying  the  same  factor  as  in  Section  4.2)  is  assumed  to  be  equiva- 
lent to  1.5  MIPS  of  available  speed.  Table  C-2  presents  the  corre- 
sponding mean  response  times  for  the  seven  categories  of  FSS  activity, 
and  may  be  compared  directly  with  Tables  4-25  and  4-26.  Such  a system 
would  be  a L'NIVAC  1100/40  multiprocessor,  costing  between  $3M  to  $5M, 
or  a burroughs  h6800  multiprocessor,  costing  between  $3M  to  $4M.* 

* Kstimates  based  on  MITRH  Working  Paper  Wl’-12218,  FSS  Hub  Sizing 
and  Costing,  by  M.  I.  (iasper.  The  current  costs  may  be  lower  due 
to  the  recent  round  of  price  cuts. 


C-1 


Slmllarlv,  Table  C- '5  summarizes  expected  waiting  times  for  a machine 
with  an  available  speed  of  about  1.1  MIPS,  and  Table  C-4  gives  the 
corresponding  mean  response  times,  which  again  may  be  compared 
directly  with  Tables  4-17  and  4-28.  Such  a system  would  be  a single 
1100/40. 
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TABI.E  C-l 


MEAN  WAITINI.  TIMf:S  FOK  1.5  EdUIVAFENT  KIPS  C.DNFia.KATION 


TYPF 

INSTR 

"■l 

'1 

2 

A PKH 

SECOND 

1.67  X 10 

-4 

1. 

ProceRRor  StatuR  Messages 
(Constant  Service  Time) 

250 

2.  78  X 

10 

5 

2 ^ 

r>at«i  Base  I'pdate 
(F.„  Service  Time) 

4 7K 

.0313 

.0013 

1 

3. 

3 

Input  t rom  Terminals* 

(t^  Service  Time) 

lOK 

.006  7 

5.93  X 

10-' 

-5 

1.25 

Output  to  Terminals,  Wx  Data 
(FlO  Service  Time) 

5K 

.0033 

1.01  X 

10 

-7 

2.69 

5. 

Output  to  Terminals,  Other 

Cat eKorles 

(K,,  Service  Time) 

IK 

.000  7 

6.6  X 

10 

.833 

6. 

I/O  Ready  Mst,  Disk  Processing 
Weather  Data  for  First  Page 
Service  Time) 

16K 

.0107 

.0002 

.253 

7. 

Flight  Plan  Processing  (Service 
Time  Parameters  as  determined 

In  Section  U.\.U.{*.2) 

86K 

.0573 

.0621 

.115 

8. 

Aircraft  Contact  Processing 
(F^  Service  Tine) 

20K 

.0133 

.0002 

-5 

.0525 

9. 

Ml  see  l laneous  Messages  ** 

(F^  Service  Time) 

9500 

.006  3 

6.02  X 

10 

6.67 

10. 

Route  Processing 
(Ejn  Service  Time) 

4 34K 

.289  3 

.0921 

.1683 

11 . 

I/O  Ready  List,  Rest  of 

Route  Brief 

(F,,  Service  Time) 

671K 

.4473 

.300 

. 1683 

12. 

I/O  Ready  List,  Rest  of 

Local  brief 

(Ej  Service  Time) 

76K 

.0507 

.0034 

.0850 

* Assumes  4SOO  per  hour,  based 

2 X 1500  • 3000  miscellaneous 

on  1500  wed 

messages . 

ther  and 

flight  plan 

nessages,  and 

**  Includes  A500  loKginK  messaKes  and  recording  of  incoming  data  for  a total  of 
16,517  + 3000  + A500  ■ 24,017  messages  per  hour. 
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E(W) 

.0002 

. 0 320 
.0077 

.0042 

.0015 

.0121 

.0653 

.0190 

.0120 
. 3 382 
. 5837 

. 1287 


TABLE  C-2 


me;an  response  times  for  categories  of  fss  activity 
(1.5  EQUIVALENT  MIPS  CONFIGURATION) 


ROITE  BRIEF  (ITEMS  3,  4,  6,  10)  .362  seconds 

DISK  ACCESSES  .656 

1.02 

LOCAL  BRIEF  (ITEMS  3,  4,  6)  .0240 

DISK  ACCESSES  .131 

.155 

n.IGHT  PLANS  (ITEMS  5,  7)  .0668 

DISK  ACCESSES  . 263 

. 330 


AIRCRAFT  CONTACTS  (ITEMS  5,  8)  .0205 

DISK  ACCESSES  .105 

.126 

mSCELLANEOUS  (ITEMS  5,  9)  .0135 

DISK  ACCESSES  .131 

.145 

REST  OF  ROUTE  BRIEF  (ITEM  11)  .584 

DISK  ACCESSES  1.838 

2.42 

REST  OF  LOCAI.  BRIEF  (ITEM  12)  .129 

DISK  ACCESSES  .656 

. 785 


TABLE  C-T 


me:an  waiting  times  for  l.l  eqltvalent  mips  configuration 


TYPE 

INSTR 

'*1 

'‘2 

> PER 
SECOND 

E(W) 

-4 

-8 

.0002 

1. 

Processor  Status  MessaKe^* 
(Conatant  Service  Time) 

2 50 

2.35  X 10 

5.54  X 

10 

5 

2. 

Data  Base  Update 
(E.J  Service  Time) 

4 7K 

.0442 

.0026 

1 

.04  56 

3. 

Input  from  Terminals 
(E^  Service  Time) 

I OK 

.0094 

.0001 

1.25 

.0114 

U. 

Output  to  Terminals,  Wx  Data 
(Ejp  Service  Time) 

5K 

.004  7 

2.44  X 

10-^ 

'6 

2.69 

.0066 

5. 

Output  to  Terminals,  Other 

Categories 

(E^  Service  Time) 

IK 

.0009 

1.33  X 

10 

.833 

.0026 

6. 

I/O  Ready  Mst,  Disk  Processing, 
Weather  Data  for  First  Page 
(E^  Service  Time) 

16K 

.0151 

.000  3 

.253 

.0179 

7. 

Flight  Plan  Processing 
(Estimated  Service  Time 
Parameter) 

86K 

.0809 

.084  7 

.115 

.0948 

S. 

Aircraft  Contact  Processing 
(E^  Service  Time) 

20K 

.0188 

.000  5 

.0525 

.0280 

9. 

Miscel laneoua  Messages 
(E^  Service  Time) 

9500 

.0089 

.0001 

6.67 

.0182 

10. 

Route  Processing 
(Ejy  Service  Time) 

434K 

.4085 

. 1835 

.1683 

.5100 

11. 

I/O  Ready  List,  Rest  of 

Route  Briefing 
(E^  Service  Time) 

671K 

.6100 

.5582 

.1683 

.9030 

12. 

I/O  Ready  List,  Rest  of 

Local  Briefing 
(E^  Service  Time) 

76K 

.0691 

.0064 

.0850 

.2502 
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TABLE  C-4 


MEAN  RESPONSE  TIMP;  FOR  CATEGORIES  OF  ESS  ACTIVITY 
(1.1  EQUIVALENT  MIPS  CONFIGURATION) 


1.  ROUTE  BRIEF  (ITEMS  3,  4,  6,  10) 
DISK  ACCESSES 


.5459  seconds 
.656 
1.20 


2.  LOCAL  BRIEF  (ITEMS  3,  4,  6)  .0359 

DISK  ACCESSES  .131 

.167 


3.  FLIGHT  PLANS  (ITEMS  5,  7)  .0974 

.263 

.360 

4.  AIRCRAFT  CONTACTS  (ITEMS  5,  8)  .0306 

DISK  ACCESSES  . 105 

.136 

5.  MISCELLANEOUS  (ITEMS  5,  9)  .0208 

DISK  ACCESSES  .131 

.152 

6.  REST  OF  ROUTE  BRIEF  (ITEM  11)  .9030 

DISK  ACCESSES  1.838 

2.  74 

7.  REST  OF  LOCAL  BRIEF  (ITEM  12)  .2502 

DISK  ACCESSES  .656 

.906 
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